InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/ccitt/1988/troff/8_2_06.tro

Text File | 1991-12-22 | 129.5 KB | 4,440 lines

.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\"                 Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P

.rs
\v'|.5i'
.sp 2P
.LP
\fB5\fR     \fBPacket formats\fR
.sp 1P
.RT
.sp 1P
.LP
5.1
    \fIGeneral\fR
.EF '%    Fascicle\ VIII.2\ \(em\ Rec.\ X.25''
.OF '''Fascicle\ VIII.2\ \(em\ Rec.\ X.25    %'
.sp 9p
.RT
.PP
The possible extension of packet formats by the addition of new
fields is for further study.
.PP
\fINote\fR \ \(em\ Any such field:
.RT
.LP
    a)
    would only be provided as an addition following all
previously defined fields, and not as an insertion between any
of the previously defined fields;
.LP
    b)
    would be transmitted to a DTE only when either the DCE has
been informed that the DTE is able to interpret this field and
act upon it, or when the DTE can ignore the field without
adversely affecting the operation of the DTE/DCE interface
(including charging);
.LP
    c)
    would not contain any information pertaining to a user
facility to which the DTE has not subscribed, unless the DTE can
ignore the facility without adversely affecting the operation of
the DTE/DCE interface (including charging).
.PP
Bits of an octet are numbered 8 to 1 where bit\ 1 is the low order bit
and is transmitted first. Octets of a packet are consecutively numbered
starting from\ 1 and are transmitted in this order.
.sp 1P
.LP
5.1.1
    \fIGeneral format identifier\fR
.sp 9p
.RT
.PP
The general format identifier field is a four bit binary coded
field which is provided to indicate the general format of the rest of the
header. The general format identifier field is located in bit positions\ 8,
7, 6 and\ 5 of octet\ 1, and bit\ 5 is the low order bit
(see Table\ 16/X.25).
.RT
.ce
\fBH.T. [T14.25]\fR
.ce
TABLE\ 16/X.25
.ce
\fBGeneral format identifier\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(168p) | cw(12p) sw(6p) sw(12p) sw(6p) , ^  | c | c | c | c.
General format identifier    Octet 1  Bits
    8    7    6    5
_
.T&
lw(84p) | lw(84p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) , ^  | l | c | c | c | c.
T{
\fICall set\(hyup\fR
\| packets
T}    T{
Sequence numbering scheme modulo 8
T}    X    X    0    1
    T{
Sequence numbering scheme modulo 128
T}    X    X    1    0
_
.T&
lw(84p) | lw(84p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) , ^  | l | c | c | c | c.
\fIClearing\fR \| packets    T{
Sequence numbering scheme modulo 8
T}    X    0    0    1
    T{
Sequence numbering scheme modulo 128
T}    X    0    1    0
_
.T&
lw(84p) | lw(84p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) , ^  | l | c | c | c | c.
T{
\fIFlow control,\fR
\fIinterrupt,\fR
\fIreset,\fR
\fIrestart,\fR
\fIregistration\fR
and
\fIdiagnostic\fR
packets
T}    T{
Sequence numbering scheme modulo 8
T}    0    0    0    1
    T{
Sequence numbering scheme modulo 128
T}    0    0    1    0
_
.T&
lw(84p) | lw(84p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) , ^  | l | c | c | c | c.
\fIData\fR \| packets    T{
Sequence numbering scheme modulo 8
T}    X    X    0    1
    T{
Sequence numbering scheme modulo 128
T}    X    X    1    0
_
.T&
lw(168p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
General format identifier extension
T}    0    0    1    1
_
.T&
lw(168p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Reserved for other applications
T}    *    *    0    T{
0
*\ Undefined.
.parag
\fINote\fR
\ \(em\ A bit which is indicated as \*QX\*U may be set to either 0 or 1,
as indicated in the text.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 16/X.25 [T14.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
Bit 8 of the general format identifier is used for the Qualifier bit in
\fIdata\fR \| packets, for the Address bit in call set\(hyup and clearing
packets, and is set to\ 0 in all other packets.
.PP
Bit\ 7 of the general format identifier is used for the delivery
confirmation procedure in \fIdata\fR \| and \fIcall set\(hyup\fR packets
and is set to\ 0 in all other packets.
.PP
Bits\ 6 and 5 are encoded for four possible indications. Two of the
codes are used to distinguish packets using modulo\ 8 sequence numbering from
packets using modulo\ 128 sequence numbering. The third code is used to
indicate an extension to an expanded format for a family of general format
identifier
codes which are a subject of further study. The fourth code is reserved for
other applications.
.PP
\fINote\ 1\fR \ \(em\ The DTE must encode the GFI to be consistent with
whether or not it has subscribed to the \fIextended packet sequence numbering\fR
facility (see \(sc\ 6.2).
.PP
\fINote\ 2\fR \ \(em\ It is envisaged that other general format identifier
codes could identify alternative packet formats.
.RT
.sp 1P
.LP
5.1.2
    \fILogical channel group number\fR
.sp 9p
.RT
.PP
The logical channel group number appears in every packet except
\fIrestart\fR , \fIdiagnostic\fR \| and \fIregistration\fR \| packets in
bit position\ 4, 3, 2
and\ 1 of octet\ 1. For each logical channel, this number has local significance
at the DTE/DCE interface.
.PP
This field is binary coded and bit 1 is the low order bit of the
logical channel group number. In \fIrestart\fR , \fIdiagnostic\fR and \fIregistration\fR
packets, this field is coded all zeros.
.RT
.sp 1P
.LP
5.1.3
    \fILogical channel number\fR
.sp 9p
.RT
.PP
The logical channel number appears in every packet except
\fIrestart\fR , \fIdiagnostic\fR \| and \fIregistration\fR \| packets in
all bit positions of
octet\ 2. For each logical channel, this number has local significance at the
DTE/DCE interface.
.PP
This field is binary coded and bit 1 is the low order bit of the
logical channel number. In \fIrestart\fR , \fIdiagnostic\fR and \fIregistration\fR
packets, this field is coded all zeros.
.RT
.sp 1P
.LP
5.1.4
    \fIPacket type identifier\fR
.sp 9p
.RT
.PP
Each packet shall be identified in octet\ 3 of the packet according to
Table\ 17/X.25.
.RT
.sp 2P
.LP
5.2
    \fICall set\(hyup and clearing packets\fR
.sp 1P
.RT
.sp 1P
.LP
5.2.1
    \fIAddress block format\fR
.sp 9p
.RT
.PP
The call set\(hyup and clearing packets contain an address block. This
address block has two possible formats: a non\(hyTDA/NZI address format
and a
TOA/NPI address format. These two formats are distinguished by bit\ 8 of the
general format identifier (A\ bit). When the A\ bit is set to\ 0, the non\(hyTOA/NPI
address format is used. When the A\ bit is set to\ 1, the TOA/NPI address
format is used.
.PP
The non\(hyTOA/NPI address format is supported by all networks. The
TOA/NPI address format may be supported by some networks, in particular by
those networks wishing to communicate with ISDNs for which the non\(hyTOA/NPI
address format provides insufficient addressing capacity.
.PP
\fINote\fR \ \(em\ Prior to 1997, packet\(hymode DTEs operating according
to case\ B of Recommendation\ X.31 (ISDN virtual circuit bearer service)
will be addressed by a maximum 12\ digit address from the E.164 numbering
plan. After 1996, such a packet\(hymode DTE may have 15\ digit E.164 address
TOA/NZI address procedures
will be required to address these DTEs. Recommendations\ E.165 and\ E.166
provide further guidance.
.PP
When transmitting a call set\(hyup or clearing packet, a DCE will use
the TOA/NPI address format if the DTE has subscribed to the \fITOA/NZI
address\fR \fIsubscription\fR facility (see \(sc\ 6.28), the non TOA/NPI
address format if it has not.
.bp
.RT
.ce
\fBH.T. [T15.25]\fR
.ce
TABLE\ 17/X.25
.ce
\fBPacket type identifier\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) sw(78p) | cw(12p) sw(6p) sw(12p) sw(6p) sw(12p) sw(6p) sw(12p) sw(6p) , l | l | c | c | c | c | c | c | c | c.
Packet type    Octet 3  Bits
From DCE to DTE    From DTE to DCE    8    7    6    5    4    3    2    1
_
.T&
cw(156p) .
T{
\fICall set\(hyup and clearing\fR
T}
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Incoming call    Call request    0    0    0    0    1    0    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Call connected    Call accepted    0    0    0    0    1    1    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Clear indication    Clear request    0    0    0    1    0    0    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE clear confirmation    DTE clear confirmation    0    0    0    1    0    1    1    1
.T&
cw(156p) .
\fIData and interrupt\fR
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE data    DTE data    X    X    X    X    X    X    X    0
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE interrupt    DTE interrupt    0    0    1    0    0    0    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE interrupt confirmation    DTE interrupt confirmation    0    0    1    0    0    1    1    1
.T&
cw(156p) .
T{
\fIFlow control and reset\fR
T}
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE RR (modulo 8)    DTE RR (modulo 8)    X    X    X    0    0    0    0    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
DCE RR (modulo 128)\|\ua\d\u)\d
T}    T{
DTE RR (modulo 128)\|\ua\d\u)\d
T}    0    0    0    0    0    0    0    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE RNR (modulo 8)    DTE RNR (modulo 8)    X    X    X    0    0    1    0    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
DCE RNR (modulo 128)\|\ua\d\u)\d
T}    T{
DTE RNR (modulo 128)\|\ua\d\u)\d
T}    0    0    0    0    0    1    0    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
    T{
DTE REJ (modulo 8)\|\ua\d\u)\d
T}    X    X    X    0    1    0    0    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
    T{
DTE REJ (modulo 128)\|\ua\d\u)\d
T}    0    0    0    0    1    0    0    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Reset indication    Reset request    0    0    0    1    1    0    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE reset confirmation    DTE reset confirmation    0    0    0    1    1    1    1    1
.T&
cw(156p) .
\fIRestart\fR
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Restart indication    Restart request    1    1    1    1    1    0    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DCE restart confirmation    DTE restart confirmation    1    1    1    1    1    1    1    1
.T&
cw(156p) .
\fIDiagnostic\fR
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Diagnostic\|\ua\d\u)\d\fR        1    1    1    1    0    0    0    1
.T&
cw(156p) .
T{
\fIRegistration\fR
\|\ua\d\u)\d
T}
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
    Registration request    1    1    1    1    0    0    1    1
.T&
lw(78p) | lw(78p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Registration confirmation        1    1    1    1    0    1    1    T{
1
\ua\d\u)\d\ Not necessarily available on every network.
.parag
\fINote\fR
\ \(em\ A bit which is indicated as \*QX\*U may be set to either 0 or 1 as
indicated in the text.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 17/X.25 [T15.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
\fINote\fR \ \(em\ The \fITOA/NPI address subscription\fR \| facility is
designated in Recommendation\ X.2 for further study (FS). In addition,
there are several
technical items associated with this TOA/NPI address format which are for
further study.
.PP
When transmitting a call set\(hyup or clearing packet, a DTE will use the
TOA/NPI address format if the DTE has subscribed to the \fITOA/NPI address\fR
\fIsubscription\fR facility, the non\(hyTOA/NPI address format if it has not.
.PP
When the address format used by one DTE in a call set\(hyup or clearing
packet is different from the address format used by the remote DTE, the
network (if it supports the TOA/NPI address format) converts from one address
format to the other (see \(sc\ 6.2.8).
.bp
.RT
.sp 1P
.LP
5.2.1.1
    \fIFormat of the address block when the A bit is set to 0\fR
\fI(non\(hyTOA/NPI address)\fR
.sp 9p
.RT
.PP
Figure 4/X.25 illustrates the format of the address block when the A\ bit
is set to\ 0.
.RT
.LP
.sp 1
.rs
.sp 22P
.ad r
\fBFigure 4/X.25 (comme tableau) [T16.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
5.2.1.1.1
    \fICalling and called DTE address length fields\fR
.sp 9p
.RT
.PP
These fields are four bits long each and consist of field length
indicators for the called and calling DTE addresses. Bits\ 4, 3, 2 and\ 1
indicate the length of the called DTE address in semi\(hyoctets. Bits\ 8, 7, 6
and\ 5 indicate the length of the calling DTE address in semi\(hyoctets.
Each DTE address length indicator is binary coded and bit\ 1 or\ 5 is the
low order bit of the indicator.
.RT
.sp 1P
.LP
5.2.1.1.2
    \fICalled and calling DTE address fields\fR
.sp 9p
.RT
.PP
Each digit of an address is coded in a semi\(hyoctet in binary coded decimal
with bit\ 5 or\ 1 being the low order bit of the digit.
.PP
Starting from the high order digit, a DTE address is coded in
consecutive octets with two digits per octet. In each octet, the higher
order digit is coded in bits\ 8, 7, 6 and\ 5.
.PP
When present, the calling DTE address field starts on the first
semi\(hyoctet following the end of the called DTE address field. Consequently,
when the number of digits of the called DTE address field is odd, the
beginning of the calling DTE address field, when present, is not octet
aligned.
.PP
When the total number of digits in the called and calling DTE address fields
is odd, a semi\(hyoctet with zeros in bits\ 4, 3, 2 and\ 1 will be
inserted after the calling DTE address field in order to maintain octet
alignment.
.PP
Further information on the coding of called and calling DTE address
fields is given in Appendix\ IV.
.bp
.PP
\fINote\fR \ \(em\ These fields may be used for optional addressing facilities
such as abbreviated addressing. The optional addressing facilities employed
as well as the coding of those facilities are for further study.
.RT
.sp 1P
.LP
5.2.1.2
    \fIFormat of the address block when the A bit is set to 1\fR
\fI(TOA/NPI address)\fR
.sp 9p
.RT
.PP
Figure 5/X.25 illustrates the format of the address block when the A\ bit
is set to\ 1.
.RT
.LP
.sp 1
.rs
.sp 22P
.ad r
\fBFigure 5/X.25 (comme tableau) [T17.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
5.2.1.2.1
    \fICalled and calling DTE address length fields\fR
.sp 9p
.RT
.PP
These fields are one octet long each and consist of field length
indicators for the called and calling DTE addresses. They indicate the
length of the called DTE address and the calling DTE address, respectively,
in
semi\(hyoctets. Each DTE address length indicator is binary coded and bit\
1 is the low order bit of the indicator.
.PP
The maximum value of a DTE address field length indicator
is\ 17.
.RT
.sp 1P
.LP
5.2.1.2.2
    \fICalled and calling DTE address fields\fR
.sp 9p
.RT
.PP
These fields respectively consist of the called DTE address when
present, and the calling DTE address when present.
.PP
Each DTE address field, when present, has three subfields: type of
address subfield (TOA), numbering plan identification subfield (NPI), address
digits subfield. The first two subfields are at the beginning of the address
and are binary coded with the values indicated in Tables\ 18/X.25
and\ 19/X.25.
.RT
.PP
\fINote\ 1\fR \ \(em\ Currently, no non\(hyBCD encodable values have been
allocated for type of address and numbering plan identification
subfields.
.PP
\fINote\ 2\fR \ \(em\ A DTE address containing type of address and numbering
plan identification subfields but no address digits subfield is
invalid.
.bp
.RT
.ce
\fBH.T. [T18.25]\fR
.ce
TABLE\ 18/X.25
.ce
\fBCoding of the type of address subfield\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(36p) | lw(42p) | cw(102p) .
Bits: or Bits:    T{
8\ \ 7\ \ 6\ \ 5
\| \
4\ \ 3\ \ 2\ \ 1
T}    T{
\| \
Type of address
\| \
\
T}
.T&
cw(78p) | lw(102p) .
(see Note 1)
_
.T&
lw(36p) | lw(42p) | lw(102p) .
    0\ \ 0\ \ 0\ \ 0    T{
Network\(hydependent number (see Note 2)
T}
.T&
lw(36p) | lw(42p) | lw(102p) .
    0\ \ 0\ \ 0\ \ 1    T{
International number (see Note 3)
T}
.T&
lw(36p) | lw(42p) | lw(102p) .
    0\ \ 0\ \ 1\ \ 0    National number (see Note 3)
.T&
lw(36p) | lw(42p) | lw(102p) .
    to be defined    T{
Complementary address alone (see Note 4)
T}
.T&
lw(36p) | lw(42p) | lw(102p) .
    other values    T{
Reserved
\fINote\ 1\fR
\ \(em\ The type of address subfield of the called DTE address field uses
bits 8, 7, 6 and 5. The type of address subfield of the calling DTE address
field uses bits\ 4, 3, 2 and\ 1 if the called DTE address field does \fInot\fR
end on an octet boundary; otherwise, it uses bits\ 8, 7, 6 and\ 5.
.parag
\fINote\ 2\fR
\ \(em\ In this case, the address digits subfield present after the type of address and numbering plan identification subfields are organized according to the network numbering plan, e.g., prefix or escape code might be present.
This case is equivalent to the use of the same code point in\ Q.931, where
it is called \*Qunknown\*U.
.parag
\fINote\ 3\fR
\ \(em\ As for Q.931, prefix or escape code shall not be included in the
address digits subfield.
.parag
\fINote\ 4\fR
\ \(em\ See Appendix IV for the definition of a complementary
address.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 18/X.25 [T18.25] + notes, p.\fR
.sp 1P
.RT
.ad b
.RT
.ce
\fBH.T. [T19.25]\fR
.ce
TABLE\ 19/X.25
.ce
\fBCoding of the numbering plan identification subfield\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(36p) | lw(42p) | cw(102p) .
Bits: or Bits:    T{
8\ \ 7\ \ 6\ \ 5
\| \
4\ \ 3\ \ 2\ \ 1
T}    T{
\| \
Numbering plan
\| \
\
T}
.T&
cw(78p) | lw(102p) .
(see Note 1)
_
.T&
lw(36p) | lw(42p) | lw(102p) .
    0\ \ 0\ \ 1\ \ 1    X.121 (see Note 2)
.T&
lw(36p) | lw(42p) | lw(102p) .
    to be defined    T{
Network\(hydependent (see Note 3)
T}
.T&
lw(36p) | lw(42p) | lw(102p) .
    other values    T{
Reserved (see Note 4)
\fINote\ 1\fR
\ \(em\ The numbering plan identification subfield of the called DTE address field uses bits 4, 3, 2 and\ 1. The numbering plan identification subfield of
the calling DTE address field uses bits\ 8, 7, 6 and\ 5 if the called DTE address does \fInot\fR
end on an octet boundary; otherwise, it uses bits\ 4, 3, 2 and\ 1.
.parag
\fINote\ 2\fR
\ \(em\ A mechanism equivalent to that provided by escape digits, as defined in Recommendation\ X.121, is not yet defined for use in conjunction whith the
TOA/NPI capability; such a mechanism will not use the numbering plan
identification subfield. Until the availability of such a mechanism
(potentially, an optional user facility), only the code point for
X.121 shall be used. The X.121 escape codes shall apply and, when they are
used,
the type of address subfield shall indicate network\(hydependent number.
.parag
\fINote\ 3\fR
\ \(em\ In this case, the address digits subfield present after the type
of address and numbering plan identification subfields are organized according to the network numbering plan, e.g., prefix or escape code might be present.
.parag
\fINote\ 4\fR
\ \(em\ Included among the reserved values are those corresponding to
numbering plan identifiers in Q.931 (e.g., F.69, E.164).
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 19/X.25 [T19.25] + notes, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The other semi\(hyoctets of a DTE address are digits, coded in binary
coded decimal with bit\ 5 or\ 1 being the low order bit of the digit. Starting
from the high order digit, the address digits are coded in consecutive
semi\(hyoctets. In each octet, the higher order digit is coded in bits\ 8, 7, 6
and\ 5.
.PP
When present, the calling DTE address field starts on the first
semi\(hyoctet following the end of the called DTE address field. Consequently,
when the number of semi\(hyoctets of the called DTE address field is odd, the
beginning of the calling DTE address field, when present, is not octet
aligned.
.PP
When the total number of semi\(hyoctets in the called and calling DTE
address fields is odd, a semi\(hyoctet with zeros in bits\ 4, 3, 2 and\
1 will be
inserted after the calling DTE address field in order to maintain octet
alignment.
.PP
Further information on the coding of called and calling DTE address
fields is given in Appendix\ IV.
.PP
\fINote\fR \ \(em\ These fields may be used for optional addressing facilities
such as abbreviated addressing. The optional addressing facilities employed
as well as the coding of those facilities are for further study.
.RT
.sp 1P
.LP
5.2.2
    \fICall request and incoming call packets\fR
.sp 9p
.RT
.PP
Figure 6/X.25 illustrates the format of \fIcall request\fR \| and
\fIincoming call\fR \| packets.
.RT
.LP
.sp 1
.rs
.sp 25P
.ad r
\fBFigure 6/X.25 (comme tableau) [T20.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
5.2.2.1
    \fIGeneral format identifier\fR
.sp 9p
.RT
.PP
Bit 8 of octet 1 (A bit) should be set as described in
\(sc\ 5.2.1.
.PP
Bit 7 of octet 1 should be set to 0 unless the mechanism defined in
\(sc\ 4.3.3 is used.
.bp
.RT
.sp 1P
.LP
5.2.2.2
    \fIAddress block\fR
.sp 9p
.RT
.PP
The address block is described in \(sc\ 5.2.1.
.RT
.sp 1P
.LP
5.2.2.3
    \fIFacility length field\fR
.sp 9p
.RT
.PP
The octet following the address block indicates the length of the facility
field, in octets. The facility length indicator is binary coded and
bit\ 1 is the low order bit of the indicator.
.RT
.sp 1P
.LP
5.2.2.4
    \fIFacility field\fR
.sp 9p
.RT
.PP
The facility field is present only when the DTE is using an
optional user facility requiring some indication in the \fIcall request\fR and
\fIincoming call\fR packets.
.PP
The coding of the facility field is defined in \(sc\(sc\ 6
and\ 7.
.PP
The facility field contains an integral number of octets. The actual maximum
length of this field depends on the facilities which are offered by the
network. However, this maximum does not exceed 109\ octets.
.PP
\fINote\fR \ \(em\ It is for further study whether another value should be
defined, relative to the total number of octets in the packet.
.RT
.sp 1P
.LP
5.2.2.5
    \fICall user data field\fR
.sp 9p
.RT
.PP
Following the facility field, the call user data field may be
present and has a maximum length of 128\ octets when used in conjunction with
the \fIfast select\fR facility described in \(sc\ 6.16, 16\ octets in the other
case.
.PP
\fINote\fR \ \(em\ Some networks require the call user data field to contain
an integral number of octets (see the note in \(sc\ 3).
.PP
When the virtual call is being established between two packet\(hymode
DTEs, the network does not act on any part of the call user data field. In
other circumstances, see Recommendation\ X.244.
.RT
.sp 1P
.LP
5.2.3
    \fICall accepted and call connected packets\fR
.sp 9p
.RT
.PP
Figure 7/X.25 illustrates the format of the \fIcall accepted\fR \| and
\fIcall connected\fR \| packets in the basic or extended format.
.RT
.sp 2P
.LP
5.2.3.1
    \fIBasic format\fR
.sp 1P
.RT
.sp 1P
.LP
5.2.3.1.1
    \fIGeneral format identifier\fR
.sp 9p
.RT
.PP
Bit 8 of octet 1 (A bit) should be set as described in
\(sc\ 5.2.1
.PP
Bit 7 of octet 1 should be set to\ 0 unless the mechanism defined in
\(sc\ 4.3.3 is used.
.RT
.sp 1P
.LP
5.2.3.1.2
    \fIAddress block\fR
.sp 9p
.RT
.PP
The address block is described in \(sc\ 5.2.1.
.PP
The use of the called and calling DTE address length fields in
\fIcall accepted\fR \| packets is only mandatory when the called DTE address
field, the calling DTE address field or the facility length field is
present.
.RT
.sp 1P
.LP
5.2.3.1.3
    \fIFacility length field\fR
.sp 9p
.RT
.PP
The octet following the address block indicates the length of the facility
field, in octets. The facility length indicator is binary coded and
bit\ 1 is the low order bit of the indicator.
.PP
The use of the facility length field in \fIcall accepted\fR packets is
only mandatory when the facility field is present.
.bp
.RT
.LP
.rs
.sp 27P
.ad r
\fBFigure 7/X.25 (comme tableau) [T21.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 1
5.2.3.1.4
    \fIFacility field\fR
.sp 9p
.RT
.PP
The facility field is present only when the DTE is using an
optional user facility requiring some indication in the \fIcall accepted\fR and
\fIcall connected\fR packets.
.PP
The coding of the facility field is defined in \(sc\(sc\ 6
and\ 7.
.PP
The facility field contains an integral number of octets. The actual maximum
length of this field depends on the facilities which are offered by the
network. However, this maximum does not exceed 109\ octets.
.PP
\fINote\fR \ \(em\ It is for further study whether another value should be
defined, relative to the total number of octets in the packet.
.RT
.sp 1P
.LP
5.2.3.2
    \fIExtended format\fR
.sp 9p
.RT
.PP
The extended format may be used only in conjunction with the \fIfast\fR
\fIselect\fR \| facility described in \(sc\ 6.16. In this case, the called
user data
field may be present and has a maximum length of 128\ octets.
.PP
The calling and called DTE address length fields and the facility
length field must be present when the called user data field is present.
.PP
\fINote\fR \ \(em\ Some networks require the called user data field to
contain an integral number of octets (see the note in \(sc\ 3).
.bp
.PP
When the virtual call is being established between two packet\(hymode
DTEs, the network does not act on any part of the called user data field.
See Recommendation\ X.244.
.RT
.sp 1P
.LP
5.2.4
    \fIClear request and clear indication packets\fR
.sp 9p
.RT
.PP
Figure 8/X.25 illustrates the format of \fIclear request\fR \| and
\fIclear indication\fR \| packets, in basic and extended formats.
.RT
.LP
.sp 1
.rs
.sp 31P
.ad r
\fBFigure 8/X.25 (comme tableau) [T22.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 2P
.LP
5.2.4.1
    \fIBasic format\fR
.sp 1P
.RT
.sp 1P
.LP
5.2.4.1.1
    \fIClearing cause field\fR
.sp 9p
.RT
.PP
Octet 4 is the clearing cause field and contains the reason for the clearing
of the call.
.PP
In the \fIclear request\fR \| packets, the clearing cause field should be
set by the DTE to one of the following values:
.RT
.LP
    bits:
    8\|
7\|
6\|
5\|
4\|
3\|
2\|
1
.LP
    value:
    0\|
0\|
0\|
0\|
0\|
0\|
0\|
0
.LP
    or:
    1\|X\|X\|X\|X\|X\|X\|X
.LP
where each X may be independently set to 0 or 1 by the DTE.
.bp
.PP
The DCE will prevent values of the clearing cause field other than those
shown above from reaching the other end of the call by either accepting
the \fIclear request\fR packet and forcing the clearing cause field to
all zeros in the corresponding \fIclear indication\fR packet, or considering
the \fIclear request\fR as an error and following the procedure described
in Annex\ C.
.PP
The coding of the clearing cause field in \fIclear indication\fR \| packets
is given in Table\ 20/X.25.
.RT
.ce
\fBH.T. [T23.25]\fR
.ce
TABLE\ 20/X.25
.ce
\fBCoding of clearing cause field in\fR
.ce
\fBclear indication packet\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) .
Bits
_
.T&
cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
8    7    6    5    4    3    2    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DTE originated    0    0    0    0    0    0    0    0
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DTE originated\|\ua\d\u)\d    1    X    X    X    X    X    X    X
_
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Number busy    0    0    0    0    0    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Out of order    0    0    0    0    1    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Remote procedure error    0    0    0    1    0    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Reverse charging acceptance not subscribed\|\ub\d\u)\d
T}    0    0    0    1    1    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Incompatible destination    0    0    1    0    0    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Fast select acceptance not subscribed\|\ub\d\u)\d
T}    0    0    1    0    1    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Ship absent\|\uc\d\u)\d    0    0    1    1    1    0    0    1
_
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Invalid facility request    0    0    0    0    0    0    1    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Acces barred    0    0    0    0    1    0    1    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Local procedure error    0    0    0    1    0    0    1    1
_
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Network congestion    0    0    0    0    0    1    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Not obtainable    0    0    0    0    1    1    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
RPOA out of order\|\ub\d\u)\d    0    0    0    1    0    1    0    T{
1
\ua\d\u)\d
When bit 8 is set to 1, the bits represented by Xs are those
included by the remote DTE in the clearing or restarting cause
field of the \fIclear\fR
or \fIrestart request\fR
packet respectively.
.parag
\ub\d\u)\d
May be received only if the corresponding optional user facility
is used.
.parag
\uc\d\u)\d
Used in the conjunction with mobile maritime service.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 20/X.25 [T23.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
5.2.4.1.2
    \fIDiagnostic code\fR
.sp 9p
.RT
.PP
Octet 5 is the diagnostic code and contains additional information on the
reason for the clearing of the call.
.PP
In a \fIclear request\fR \| packet, the diagnostic code is not
mandatory.
.PP
In a \fIclear indication\fR \| packet, if the clearing cause field indicates
\*QDTE originated\*U, the diagnostic code is passed unchanged from the
clearing
DTE. If the clearing DTE has not provided a diagnostic code in its \fIclear\fR
\fIrequest\fR packet, then the bits of the diagnostic code in the resulting
\fIclear\fR \fIindication\fR packet will all be zero.
.PP
When a \fIclear indication\fR \| packet results from a \fIrestart request\fR \|
packet, the value of the diagnostic code will be that specified in the
\fIrestart request\fR packet, or all zeros in the case where no diagnostic
code has been specified in the \fIrestart request\fR packet.
.PP
When the clearing cause field does not indicate \*QDTE originated\*U, the
diagnostic code in a \fIclear indication\fR packet is network generated.
Annex\ E
lists the codings for network generated diagnostics. The bits of the diagnostic
code are all set to\ 0 when no specific additional information for the
clearing is supplied.
.bp
.PP
\fINote\fR \ \(em\ The contents of the diagnostic code field do not alter the
meaning of the cause field. A DTE is not required to undertake any action on
the contents of the diagnostic code field. Unspecified code combinations
in the diagnostic code field shall not cause the DTE to refuse the cause
field.
.RT
.sp 1P
.LP
5.2.4.2
    \fIExtended format\fR
.sp 9p
.RT
.PP
The extended format is used for \fIclear request\fR \| and \fIclear\fR
\fIindication\fR \| packets only when the DTE or the DCE need to use the called
and/or calling DTE address fields, the facility field and/or the clear user
data field in conjunction with one or several optional user facilities
described in \(sc\(sc\ 6 and\ 7. The called DTE address field is used only
when the
\fIcalled line address modified notification\fR facility is used in clearing,
in
response to an \fIincoming call\fR or \fIcall request\fR packet.
.PP
When the extended format is used, the diagnostic code field, the DTE address
length fields and the facility length field must be present.
Optionally, the clear user data field may also be present.
.RT
.sp 1P
.LP
5.2.4.2.1
    \fIAddress block\fR
.sp 9p
.RT
.PP
The address block is described in \(sc\ 5.2.1.
.RT
.sp 1P
.LP
5.2.4.2.2
    \fIFacility length field\fR
.sp 9p
.RT
.PP
The octet following the address block indicates the length of the facility
field, in octets. The facility length indicator is binary coded and
bit\ 1 is the low order bit of the indicator.
.RT
.sp 1P
.LP
5.2.4.2.3
    \fIFacility field\fR
.sp 9p
.RT
.PP
The facility field is present in the \fIclear request\fR \| or the
\fIclear indication\fR packet only in conjunction with one or several optional
user facilities requiring some indication in this packet.
.PP
The coding of the facility field is defined in \(sc\(sc\ 6
and\ 7.
.PP
The facility field contains an integral number of octets. The actual maximum
length of this field depends on the facilities which are offered by the
network. However, this maximum does not exceed 109\ octets.
.PP
\fINote\fR \ \(em\ It is for further study whether another value should be
defined, relative to the total number of octets in the packet.
.RT
.sp 1P
.LP
5.2.4.2.4
    \fIClear user data field\fR
.sp 9p
.RT
.PP
This field may be present only in conjunction with the \fIfast\fR
\fIselect\fR \| facility (see \(sc\ 6.16) or the \fIcall deflection selection\fR
facility
(see \(sc\ 6.25.2.2). It has a maximum length of 128\ octets in the first
case, of 16\ or 128\ octets in the second case: whether the maximum length
is 16\ or
128\ octets when using the \fIcall deflection selection\fR facility is
specified in \(sc\ 6.25.2.2.
.PP
\fINote\ 1\fR \ \(em\ Some networks require the clear user data field to
contain an integral number of octets (see the note in \(sc\ 3).
.PP
\fINote 2\fR \ \(em\ The network does not act on any part of the clear
user data field. See Recommendation\ X.244.
.RT
.sp 1P
.LP
5.2.5
    \fIDTE and DCE clear confirmation packets\fR
.sp 9p
.RT
.PP
Figure 9/X.25 illustrates the format of the \fIDTE\fR and \fIDCE clear\fR
\fIconfirmation\fR \| packets, in the basic or extended format.
.bp
.RT
.LP
.rs
.sp 24P
.ad r
\fBFigure 9/X.25 (comme tableau) [T24.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.PP
The extended format may be used for \fIDCE clear confirmation\fR \|
packets only in conjunction with the \fIcharging information\fR facility
described in \(sc\ 6.22. It is not used for \fIDTE clear confirmation\fR
packet.
.sp 1P
.LP
5.2.5.1
    \fIAddress block\fR
.sp 9p
.RT
.PP
The address block is described in \(sc\ 5.2.1.
.PP
The calling and called DTE address length fields are coded with all
zeros and the called and calling DTE address fields are not present.
.RT
.sp 1P
.LP
5.2.5.2
    \fIFacility length field\fR
.sp 9p
.RT
.PP
The octet following the address block indicates the length of the facility
field, in octets. The facility length indicator is binary coded and
bit\ 1 is the low order bit of the indicator.
.RT
.sp 1P
.LP
5.2.5.3
    \fIFacility field\fR
.sp 9p
.RT
.PP
The coding of the facility field is defined in \(sc\(sc\ 6 and\ 7.
.PP
The facility field contains an integral number of octets. The actual maximum
length of this field depends on the facilities which are offered by the
network. However, this maximum does not exceed 109\ octets.
.PP
\fINote\fR \ \(em\ It is for further study whether another value should be
defined, relative to the total number of octets in the packet.
.bp
.RT
.sp 2P
.LP
5.3
    \fIData and interrupt packets\fR
.sp 1P
.RT
.sp 1P
.LP
5.3.1
    \fIDTE and DCE data packets\fR
.sp 9p
.RT
.PP
Figure 10/X.25 illustrates the format of the \fIDTE\fR \|and \fIDCE data\fR
\|packets.
.RT
.LP
.sp 4
.rs
.sp 37P
.ad r
\fBFigure 10/X.25 (comme tableau) [T25.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 5P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.sp 1P
.LP
5.3.1.1
    \fIQualifier (Q) bit\fR
.sp 9p
.RT
.PP
Bit 8 of octet 1 is the qualifier (Q) bit.
.RT
.sp 1P
.LP
5.3.1.2
    \fIDelivery confirmation (D) bit\fR
.sp 9p
.RT
.PP
Bit 7 of octet 1 is the delivery confirmation (D) bit.
.RT
.sp 1P
.LP
5.3.1.3
    \fIPacket receive sequence number\fR
.sp 9p
.RT
.PP
Bits 8, 7 and 6 of octet\ 3, or bits\ 8 through\ 2 of octet\ 4 when
extended, are used for indicating the packet receive sequence number\ P(R).
P(R)\ is binary coded and bit\ 6, or bit\ 2 when extended, is the low order
bit.
.RT
.sp 1P
.LP
5.3.1.4
    \fIMore Data bit\fR
.sp 9p
.RT
.PP
Bit 5 in octet 3, or bit 1 in octet 4 when extended, is used for
the
More Data mark (M\ bit)
: 0 for no more data and 1 for more
data.
.RT
.sp 1P
.LP
5.3.1.5
    \fIPacket send sequence number\fR
.sp 9p
.RT
.PP
Bits 4, 3 and 2 of octet\ 3, or bits\ 8 through 2 of octet\ 3 when
extended, are used for indicating the packet send sequence number\ P(S).
P(S) is binary coded and bit\ 2 is the low order bit.
.RT
.sp 1P
.LP
5.3.1.6
    \fIUser data field\fR
.sp 9p
.RT
.PP
Bits following octet\ 3, or octet\ 4 when extended, contain user
data.
.PP
\fINote\fR \ \(em\ Some networks require the user data field to contain an
integral number of octets (see the note in\ \(sc\ 3).
.RT
.sp 1P
.LP
5.3.2
    \fIDTE and DCE interrupt packets\fR
.sp 9p
.RT
.PP
Figure\ 11/X.25 illustrates the format of the \|\fIDTE\fR and \fIDCE\fR
\fIinterrupt\fR \|packets.
.RT
.LP
.sp 2
.rs
.sp 18P
.ad r
\fBFigure 11/X.25 (comme tableau) [T26.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
5.3.2.1
    \fIInterrupt user data field\fR
.sp 9p
.RT
.PP
Octet 4 and any following octets contain the interrupt user data. This
field may contain from\ 1 to\ 32\ octets.
.PP
\fINote\fR \ \(em\ Some networks require the interrupt user data field to
contain  an integral number of octets
(see the note in \(sc\ 3).
.RT
.sp 1P
.LP
5.3.3
    \fIDTE and DCE interrupt confirmation packets\fR
.sp 9p
.RT
.PP
Figure 12/X.25 illustrates the format of the \fIDTE\fR \|and \fIDCE\fR
\fIinterrupt confirmation\fR \|packets.
.RT
.LP
.sp 4
.rs
.sp 16P
.ad r
\fBFigure 12/X.25 (comme tableau) [T27.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 18P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.sp 2P
.LP
5.4
    \fIFlow control and reset packets\fR
.sp 1P
.RT
.sp 1P
.LP
5.4.1
    \fIDTE and DCE receive ready (RR) packets\fR
.sp 9p
.RT
.PP
Figure 13/X.25 illustrates the format of the \fIDTE\fR \|and \fIDCE RR\fR
\|packets.
.RT
.LP
.sp 5
.rs
.sp 31P
.ad r
\fBFigure 13/X.25 (comme tableau) [T28.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.sp 1P
.LP
5.4.1.1
    \fIPacket receive sequence number\fR
.sp 9p
.RT
.PP
Bits 8, 7 and 6 of octet\ 3, or bits\ 8 through\ 2 of octet\ 4 when
extended, are used for indicating the packet receive sequence number\ P(R).
P(R) is binary coded and bit\ 6, or bit\ 2 when extended, is the low order
bit.
.bp
.RT
.sp 1P
.LP
5.4.2
    \fIDTE and DCE receive not ready (RNR) packets\fR
.sp 9p
.RT
.PP
Figure 14/X.25 illustrates the format of the \fIDTE\fR \| and \fIDCE RNR\fR
\| packets.
.RT
.LP
.sp 5
.rs
.sp 31P
.ad r
\fBFigure 14/X.25 (comme tableau) [T29.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.sp 1P
.LP
5.4.2.1
    \fIPacket receive sequence number\fR
.sp 9p
.RT
.PP
Bits 8, 7 and 6 of octet\ 3, or bits\ 8 through\ 2 of octet\ 4 when
extended, are used for indicating the packet receive sequence number\ P(R).
P(R) is binary coded and bit\ 6, or bit\ 2 when extended, is the low order
bit.
.bp
.RT
.sp 1P
.LP
5.4.3
    \fIReset request and reset indication packets\fR
.sp 9p
.RT
.PP
Figure\ 15/X.25 illustrates the format of the \fIreset request\fR \|and
\fIreset indication\fR \|packets.
.RT
.LP
.sp 4
.rs
.sp 21P
.ad r
\fBFigure 15/X.25 (comme tableau) [T30.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 4
.sp 1P
.LP
5.4.3.1
    \fIResetting cause field\fR
.sp 9p
.RT
.PP
Octet 4 is the resetting cause field and contains the reason for
the reset.
.PP
In \fIreset request\fR \|packets, the resetting cause field should be set
by the DTE to one of the following values:
.RT
.LP
    bits:
    8\|
7\|
6\|
5\|
4\|
3\|
2\|
1
.LP
    value:
    0\|
0\|
0\|
0\|
0\|
0\|
0\|
0
.LP
    or:
    1\|X\|X\|X\|X\|X\|X\|X
.LP
where each X may be independently set to 0 or 1 by the DTE.
.PP
The DCE will prevent values of the resetting cause field, other
than those shown above, from reaching the other end of the virtual call or
permanent virtual circuit by either accepting the \fIreset request\fR packet
and
forcing the resetting cause field to all zeros in the corresponding \fIreset\fR
\fIindication\fR packet, or considering the reset request as an error and
following the procedure described in Annex\ C.
.PP
The coding of the resetting cause field in a \fIreset indication\fR
\|packet is given in Table\ 21/X.25.
.bp
.RT
.ce
\fBH.T. [T31.25]\fR
.ce
TABLE\ 21/X.25
.ce
\fBCoding of resetting cause field\fR
.ce
\fBin reset indication packet\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) .
Bits
_
.T&
cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
8    7    6    5    4    3    2    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DTE originated    0    0    0    0    0    0    0    0
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
DTE originated\|\ua\d\u)\d    1    X    X    X    X    X    X    X
_
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Out or order\|\ub\d\u)\d    0    0    0    0    0    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Remote procedure error    0    0    0    0    0    0    1    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Local procedure error    0    0    0    0    0    1    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Network congestion    0    0    0    0    0    1    1    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Remote DTE operational\|\ub\d\u)\d
T}    0    0    0    0    1    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Network operational\|\ub\d\u)\d
T}    0    0    0    0    1    1    1    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Incompatible destination    0    0    0    1    0    0    0    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Network out of order\|\ub\d\u)\d
T}    0    0    0    1    1    1    0    T{
1
\ua\d\u)\d
When bit 8 is set to 1, the bits represented by Xs are those
indicated by the remote DTE in the resetting cause field
(virtual calls and permanent virtual circuits) or the restarting
cause field (permanent virtual circuits only) of
the \fIreset\fR
or \fIrestart request\fR
packet, respectively.
.parag
\ub\d\u)\d
Applicable to permanent virtual circuits only.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 21/X.25 [T31.25] p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.sp 1P
.LP
5.4.3.2
    \fIDiagnostic code\fR
.sp 9p
.RT
.PP
Octet\ 5 is the diagnostic code and contains additional information on
the reason for the reset.
.PP
In a \fIreset request\fR \|packet the diagnostic code is not
mandatory.
.PP
In a \fIreset indication\fR \|packet, if the resetting cause field
indicates \*QDTE originated\*U, the diagnostic code has been passed unchanged
from the resetting DTE. If the DTE requesting a reset has not provided
a diagnostic code in its \fIreset request\fR packet, then the bits of the
diagnostic code in the resulting \fIreset indication\fR packet will all
be zeros.
.PP
When a \fIreset indication\fR \|packet results from a \fIrestart request\fR
\|packet, the value of the diagnostic code will be that specified in the
\fIrestart request\fR packet, or all zeros in the case where no diagnostic code
has been specified in the \fIrestart request\fR packet.
.PP
When the resetting cause field does not indicate \*QDTE originated\*U,
the diagnostic code in a \fIreset indication\fR \| packet is network generated.
Annex\ E lists the codings for network generated diagnostics. The bits
of the diagnostic code are all set to 0 when no specific additional information
for the reset is supplied.
.PP
\fINote\fR \ \(em\ The contents of the diagnostic code field do not alter the
meaning of the cause field. A DTE is not required to undertake any action on
the contents of the diagnostic code field. Unspecified code combinations
in the diagnostic code field shall not cause the DTE to not accept the
cause
field.
.bp
.RT
.sp 1P
.LP
5.4.4
    \fIDTE and DCE reset confirmation packets\fR
.sp 9p
.RT
.PP
Figure 16/X.25 illustrates the format of the \fIDTE\fR \|and \fIDCE reset\fR
\fIconfirmation\fR \|packets.
.RT
.LP
.sp 1
.rs
.sp 16P
.ad r
\fBFigure 16/X.25 (comme tableau) [T32.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 2P
.LP
5.5
    \fIRestart packets\fR
.sp 1P
.RT
.sp 1P
.LP
5.5.1
    \fIRestart request and restart indication packets\fR
.sp 9p
.RT
.PP
Figure 17/X.25 illustrates the format of the \fIrestart request\fR \|and
\fIrestart indication\fR \|packets.
.RT
.LP
.sp 1
.rs
.sp 21P
.ad r
\fBFigure 17/X.25 (comme tableau) [T33.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
5.5.1.1
    \fIRestarting cause field\fR
.sp 9p
.RT
.PP
Octet 4 is the restarting cause field and contains the reason for the restart.
.PP
In \fIrestart request\fR \|packets, the restarting cause field should be
set by the DTE to one of the following values:
.RT
.LP
    bits:
    8\|
7\|
6\|
5\|
4\|
3\|
2\|
1
.LP
    value:
    0\|
0\|
0\|
0\|
0\|
0\|
0\|
0
.LP
    or:
    1\|X\|X\|X\|X\|X\|X\|X
.LP
where each X may be independently set to 0 or 1 by the DTE.
.PP
The DCE will prevent values of the restarting cause field, other than those
shown above, from reaching the other end of the virtual calls and/or permanent
virtual circuits by either accepting the \fIrestart request\fR packet and
forcing the clearing or resetting cause field to all zeros in the corresponding
\fIclear\fR and/or \fIreset indication\fR packets, or considering the restart
request as an error and following the procedure described in Annex\ C.
.PP
The coding of the restarting cause field in the \fIrestart indication\fR
\|packets is given in Table\ 22/X.25.
.RT
.LP
.sp 1
.ce
\fBH.T. [T34.25]\fR
.ce
TABLE\ 22/X.25
.ce
\fBCoding of restarting cause field\fR
.ce
\fBin restart indication packet\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) .
Bits
_
.T&
cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
8    7    6    5    4    3    2    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Local procedure error    0    0    0    0    0    0    0    1
_
.T&
lw(108p) | lw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Network congestion    0    0    0    0    0    0    1    1
.T&
lw(108p) | lw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Network operational    0    0    0    0    0    1    1    1
.T&
lw(108p) | lw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Registration/cancellation confirmed\|\ua\d\u)\d
T}    0    1    1    1    1    1    1    T{
1
\ua\d\u)\d
May be received only if the optional
\fIon\(hyline facility registration\fR
\| facility
is used.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 22/X.25 [T34.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
5.5.1.2
    \fIDiagnostic code\fR
.sp 9p
.RT
.PP
Octet 5 is the diagnostic code and contains additional information on the
reason for the restart.
.PP
In a \fIrestart request\fR \|packet, the diagnostic code is not mandatory.
The diagnostic code, if specified, is passed to the corresponding DTEs
as the diagnostic code of a \fIreset indication\fR packet for permanent
virtual circuits or a \fIclear indication\fR packet for virtual calls.
.PP
The coding of the diagnostic code field in a \fIrestart indication\fR
\|packet is given in Annex\ E. The bits of the diagnostic code are all set to
zero when no specific additional information for the restart is supplied.
.PP
\fINote\fR \ \(em\ The contents of the diagnostic code field do not alter the
meaning of the cause field. A DTE is not required to undertake any action on
the contents of the diagnostic code field. Unspecified code combinations
in the diagnostic code field shall not cause the DTE to not accept the
cause
field.
.bp
.RT
.sp 1P
.LP
5.5.2
    \fIDTE and DCE restart confirmation packets\fR
.sp 9p
.RT
.PP
Figure 18/X.25 illustrates the format of the \fIDTE\fR \| and \fIDCE\fR
\fIrestart confirmation\fR \|packets.
.RT
.LP
.sp 1
.rs
.sp 16P
.ad r
\fBFigure 18/X.25 (comme tableau) [T35.25] p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.sp 1P
.LP
5.6
    \fIDiagnostic packet\fR
.sp 9p
.RT
.PP
Figure 19/X.25 illustrates the format of the \fIdiagnostic\fR
\|packet.
.RT
.LP
.sp 1
.rs
.sp 22P
.ad r
\fBFigure 19/X.25 (comme tableau) [T36.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
5.6.1
    \fIDiagnostic code field\fR
.sp 9p
.RT
.PP
Octet 4 is the diagnostic code and contains information on the
error condition which resulted in the transmission of the \fIdiagnostic\fR
packet. The coding of the diagnostic code field is given in Annex\ E.
.RT
.sp 1P
.LP
5.6.2
    \fIDiagnostic explanation field\fR
.sp 9p
.RT
.PP
When the \fIdiagnostic\fR \|packet is issued as a result of the
reception of an erroneous packet from the DTE (see Tables\ C\(hy1/X.25 and
C\(hy2/X.25), this field contains the first three octets of header information
from the erroneous DTE packet. If the packet contains less than 3\ octets,
this field contains whatever bits were received.
.PP
When the \fIdiagnostic\fR \|packet is issued as a result of a DCE time\(hyout
(see Table\ D\(hy1/X.25), the diagnostic explanation field contains 2\
octets coded as follows:
.RT
.LP
    \(em
    bits 8, 7, 6 and 5 of the first octet contain the general
format identifier for the interface;
.LP
    \(em
    bits 4 to 1 of the first octet and bits 8 to 1 of the second
octet are all\ 0 for expiration of time\(hyout T10 and give the
number of the  logical channel on which the time\(hyout occurred
for expiration of time\(hyout\ T12 or\ T13.
.sp 2P
.LP
5.7
    \fIPackets required for optional user facilities\fR
.sp 1P
.RT
.sp 1P
.LP
5.7.1
    \fIDTE reject (REJ) packet for the packet retransmission facility\fR
.sp 9p
.RT
.PP
Figure\ 20/X.25 illustrates the format of the \fIDTE REJ\fR \|packet,
used in conjunction with the \fIpacket retransmission\fR facility described in
\(sc\ 6.4.
.RT
.LP
.rs
.sp 32P
.ad r
\fBFigure 20/X.25 (comme tableau) [T37.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
5.7.1.1
    \fIPacket receive sequence number\fR
.sp 9p
.RT
.PP
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when
extended, are used for indicating the packet receive sequence number\ P(R).
P(R) is binary coded and bit\ 6, or bit\ 2 when extended, is the low order
bit.
.RT
.sp 2P
.LP
5.7.2
     \fIRegistration packets for the on\(hyline facility registration\fR \fIfacility\fR
.sp 1P
.RT
.sp 1P
.LP
5.7.2.1
    \fIRegistration request packet\fR
.sp 9p
.RT
.PP
Figure 21/X.25 illustrates the format of the
\fIregistration\fR
\fIrequest\fR \|packet.
.RT
.LP
.rs
.sp 28P
.ad r
\fBFigure 21/X.25 (comme tableau) [T38.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
5.7.2.1.1
    \fIAddress length fields\fR
.sp 9p
.RT
.PP
Octet 4 consists of the field length indicators for the DTE and DCE addresses.
Bits\ 4, 3, 2 and\ 1 indicate the length of the DCE address in
semi\(hyoctets. Bits\ 8, 7, 6 and\ 5 indicate the length of the DTE address in
semi\(hyoctets. Each address length indicator is binary coded and bit\
1 or\ 5 is
the low order bit of the indicator.
.PP
These fields are coded with all zeros under the procedures in this
Recommendation.
.RT
.sp 1P
.LP
5.7.2.1.2
    \fIAddress field\fR
.sp 9p
.RT
.PP
Octet\ 5 and the following octets consist of the DCE address, when present,
and the DTE address, when present.
.PP
Each digit of an address is coded in a semi\(hyoctet in binary coded
decimal with bit\ 5 or\ 1 being the low order bit of the digit.
.bp
.PP
Starting from the high order digit, the address is coded in octet\ 5
and consecutive octets with two digits per octet. In each octet, the higher
order digit is coded in bits\ 8, 7, 6 and\ 5.
.PP
The address field shall be rounded up to an integral number of octets by
inserting zeros in bits\ 4, 3, 2 and\ 1 of the last octet of the field
when
necessary.
.PP
This field is not present under the procedures in this
Recommendation.
.RT
.sp 1P
.LP
5.7.2.1.3
    \fIRegistration length field\fR
.sp 9p
.RT
.PP
The octet following the address field indicates the length of the registration
field in octets. The registration length indicator is binary coded and
bit\ 1 is the low order bit of the indicator.
.RT
.sp 1P
.LP
5.7.2.1.4
    \fIRegistration field\fR
.sp 9p
.RT
.PP
The registration field is present only when the DTE wishes to
request the DCE to agree to, or to stop a previous agreement for, an optional
user facility.
.PP
The coding of the registration field is defined in \(sc\ 7.3.
.PP
The registration field contains an integral number of octets. The
actual maximum length of this field depends on the network. However, this
maximum does not exceed 109\ octets.
.RT
.sp 1P
.LP
5.7.2.2
    \fIRegistration confirmation packet\fR
.sp 9p
.RT
.PP
Figure 18/X.25 illustrates the format of the \fIregistration\fR
\fIconfirmation\fR \|packet.
.RT
.LP
.rs
.sp 32P
.ad r
\fBFigure 22/X.25 (comme tableau) [T39.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
5.7.2.2.1
    \fICause field\fR
.sp 9p
.RT
.PP
Octet 4 is the cause field and contains the cause of any failure in negotiation
of facilities or an indication that the registration field was
verified by the DCE.
.PP
The coding of the cause field in the \fIregistration confirmation\fR
\|packet is shown in Table\ 23/X.25.
.RT
.ce
\fBH.T. [T40.25]\fR
.ce
TABLE\ 23/X.25
.ce
\fBCoding of cause field in registration\fR
.ce
\fBconfirmation packet\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) .
Bits
_
.T&
cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
8    7    6    5    4    3    2    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
T{
Registration/cancellation confirmed
T}    0    1    1    1    1    1    1    1
_
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Invalid facility request    0    0    0    0    0    0    1    1
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Local procedure error    0    0    0    1    0    0    1    1
_
.T&
lw(108p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
Network congestion    0    0    0    0    0    1    0    1
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 23/X.25 [T40.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
5.7.2.2.2
    \fIDiagnostic code\fR
.sp 9p
.RT
.PP
Octet 5 is the diagnostic code and contains additional information on the
reason for failure of facilities negotiation.
.PP
Annex E lists the coding for diagnostics. The bits of the diagnostic code
are all set to\ 0 when negotiation is successful, or when no additional
information is supplied.
.RT
.sp 1P
.LP
5.7.2.2.3
    \fIAddress length fields\fR
.sp 9p
.RT
.PP
Octet\ 6 consists of the field length indicators for the DTE and DCE addresses.
Bits\ 4, 3, 2 and\ 1 indicate the length of the DCE address in
semi\(hyoctets. Bits\ 8, 7, 6 and\ 5 indicate the length of the DTE address in
semi\(hyoctets. Each address length indicator is binary coded and bit\
1 or\ 5 is
the low order bit of the indicator.
.PP
These fields are coded with all zeros under the procedures in this
Recommendation.
.RT
.sp 1P
.LP
5.7.2.2.4
    \fIAddress field\fR
.sp 9p
.RT
.PP
Octet 7 and the following octets consist of the DCE address, when present,
and the DTE address, when present.
.PP
Each digit of an address is coded in a semi\(hyoctet in binary coded
decimal with bit\ 5 or\ 1 being the low order bit of the digit.
.PP
Starting from the high order digit, the address is coded in octet\ 7
and consecutive octets with two digits per octet. In each octet, the higher
order digit is coded in bits\ 8, 7, 6 and\ 5.
.PP
The address field shall be rounded up to an integral number of octets by
inserting zeros in bits\ 4, 3, 2 and\ 1 of the last octet of the field
when
necessary.
.PP
This field is not present under the procedures in this
Recommendation.
.bp
.RT
.sp 1P
.LP
5.7.2.2.5
    \fIRegistration length field\fR
.sp 9p
.RT
.PP
The octet following the address field indicates the length of the registration
field, in octets. The registration length indicator is binary
coded and bit\ 1 is the low order bit of the indicator.
.RT
.sp 1P
.LP
5.7.2.2.6
    \fIRegistration field\fR
.sp 9p
.RT
.PP
The registration field is used to indicate which optional user
facilities are available, and which are currently in effect.
.PP
The coding of the registration field is defined in \(sc\ 7.3.
.PP
The registration field contains an integral number of octets. The
actual maximum length of this field depends on the network. However, this
maximum does not exceed 109\ octets.
.RT
.sp 2P
.LP
\fB6\fR     \fBProcedures for optional user facilities
(packet layer)\fR
.sp 1P
.RT
.sp 1P
.LP
6.1
    \fIOn\(hyline facility registration\fR
.sp 9p
.RT
.PP
\fIOn\(hyline facility registration\fR \| is an optional user facility
agreed for a period of time. This facility, if subscribed to, permits the
DTE at any time to request registration of facilities, or obtain current
values of facilities as understood by the DCE, by transferring across the
DTE/DCE
interface a \fIregistration request\fR \| packet.
.PP
The DCE will, in response to a \fIregistration packet\fR , report the
current value of all facilities applicable to the DTE/DCE interface, by
transferring a \fIregistration confirmation\fR \|packet across the DTE/DCE
interface. Optional facilities which are not offered by the network will
not be reported in the \fIregistration confirmation\fR \|packet. To avoid
requesting
facilities that are not available in a particular network, or values that
are not allowed, the DTE may transfer a \fIregistration request\fR \| packet
across the DTE/DCE interface containing no optional facilities. It may
then modify any
negotiable facilities reported in the corresponding \fIregistration\fR
\fIconfirmation\fR \| packet by transferring a second \fIregistration request\fR
\| packet across the DTE/DCE interface.
.PP
When the DCE returns the \fIregistration confirmation\fR \| packet, the
facilities values shown are in effect for any subsequent virtual calls.
The values of the \fIextended packet sequence numbering\fR , \fIpacket\fR
\fIretransmission\fR , and \fID\ bit modification\fR \| facilities and
the allocation of
logical channel type ranges can be modified only when there are no virtual
calls (i.e.,\ all logical channels used for virtual calls are in state\ p1).
When these facilities take effect and when there is one or more logical
channels assigned to permanent virtual circuits, the network restarts the
interface with the cause \*QRegistration/cancellation confirmed\*U and the
diagnostic \*QNo additional information\*U in order to change the values of the
permanent virtual circuits at the interface. At the remote end of each
permanent virtual circuit, the corresponding \fIreset indication\fR \|
packet is sent with the cause \*QRemote DTE operational\*U and the diagnostic
\*QNo additional
information\*U.
.PP
If a requested value of a particular facility is not allowed, the DCE shall
report in the \fIregistration confirmation\fR \| packet:
.RT
.LP
    a)
    if the facility has a boolean value, the value
allowed;
.LP
    b)
    if the value is greater than the maximum allowed value of
that facility, the maximum allowed value; or
.LP
    c)
     if the value is less than the minimum allowed value of that facility,
the minimum allowed value.
.PP
The \fIregistration confirmation\fR \| packet shall also contain an
appropriate cause code. The DTE may choose to accept the value reported
by the DCE or to attempt to negotiate another value for the requested facilities.
.PP
If the DCE cannot make all the modifications requested in a
\fIregistration request\fR \| packet, it will not alter the values of some
facilities. Circumstances in which the DCE can not make all of the
modifications requested include:
.RT
.LP
    a)
    conflict in facilities settings, and
.LP
    b)
    when the interface has at least one virtual call
established when attempting to negotiate those facilities
that require all virtual call logical channels to be in
state\ p1 (including the collision of an \fIincoming call\fR \|
packet and a \fIregistration request\fR \| packet).
.PP
The DTE should wait for the \fIregistration confirmation\fR \| packet
before sending a \fIcall request\fR \| packet, or sending a packet on a
permanent
virtual circuit.
.bp
.PP
For every optional user facility, Annex F indicates:
.RT
.LP
    \(em
    if the value of the facility may be negotiated;
.LP
    \(em
    if the \fIregistration confirmation\fR \| packets indicate
whether or not the facility is supported by
the DCE;
.LP
    \(em
    if the value of the facility may be altered by the DTE
either only when every logical channel used for virtual
calls is in state\ p1, or in any packet layer state.
.PP
Indication in \fIregistration confirmation\fR \| packet of whether the
\fINUI override\fR \| facility is supported by the network is for further
study.
.PP
A fault condition within the network may affect the facilities
previously negotiated by means of \fIregistration\fR \| packets. In this
situation, the DCE initiates the restart procedure to inform the DTE of
the
failure.
.PP
A restart procedure initiated by the DTE does not affect the
facilities values. When the DCE initiates the restart procedure with the
cause \*QLocal procedure error\*U, the facilities values are not affected.
When the DCE initiates the restart procedure with the cause \*QNetwork
congestion\*U or \*QNetwork operational\*U, the values of facilities previously
negotiated may be affected. When the DCE initiates the restart procedure
with the cause
\*QRegistration/cancellation confirmed\*U, the facilities values are as set
by the related registration procedure.
.RT
.sp 1P
.LP
6.2
    \fIExtended packet sequence numbering\fR
.sp 9p
.RT
.PP
\fIExtended packet sequence numbering\fR \| is an optional user facility
agreed for a period of time. It is common to all logical channels at the
DTE/DCE interface.
.PP
This user facility, if subscribed to, provides sequence numbering of packets
performed modulo\ 128. In the absence of this facility, the sequence
numbering of packets is performed modulo\ 8.
.RT
.sp 1P
.LP
6.3
    \fID bit modification\fR
.sp 9p
.RT
.PP
\fID bit modification\fR \| is an optional user facility agreed for a
period of time. This facility applies to all virtual calls and permanent
virtual circuits at the DTE/DCE interface. This facility is only intended
for use by those DTEs implemented prior to the introduction of the D\ bit
procedure which were designed for operation on public data networks that
support
end\(hyto\(hyend P(R) significance. It allows these DTEs to continue to operate
with end\(hyto\(hyend P(R) significance within a national network.
.PP
For communication within the national network, this facility, when
subscribed to:
.RT
.LP
    a)
    will change from 0 to 1 the value of bit 7 of the GFI
in all \fIcall request\fR \| and \fIcall accepted\fR \| packets and the
value of the D\ bit in all \fIDTE data\fR \| packets received from
the DTE, and
.LP
    b)
    will set to 0 the value of bit 7 of the GFI in all
\fIincoming call\fR \| and \fIcall connected\fR \| packets, and the
value of the D\ bit in all \fIDCE data\fR \| packets transmitted to
the DTE.
.PP
For international operation, conversion b) above applies and
conversion\ a) above does not apply. Other conversion rules for international
operation are for bilateral agreement between Administrations.
.sp 1P
.LP
6.4
    \fIPacket retransmission\fR
.sp 9p
.RT
.PP
\fIPacket retransmission\fR \| is an optional user facility agreed for
a period of time. It is common to all logical channels at the DTE/DCE
interface.
.PP
This user facility, if subscribed to, allows a DTE to request
retransmission of one or several consecutive \fIDCE data\fR \| packets
from the DCE by transferring across the DTE/DCE interface a \fIDTE reject\fR
\| packet specifying a logical channel number and a sequence number P(R).
The value of this P(R)
should be within the range from the last P(R) received by the DCE up to, but
not including, the P(S) of the next \fIDCE data\fR \| packet to be transmitted
by the DCE. If the P(R) is outside this range, the DCE will initiate the
reset
procedure with the cause \*QLocal procedure error\*U and
diagnostic\ ##\ 2.
.PP
When receiving a \fIDTE reject\fR \| packet, the DCE initiates on the
specified logical channel retransmission of the \fIDCE data\fR \| packets,
the packet send sequence numbers of which are starting from P(R), where
P(R) is indicated in the \fIDTE reject\fR \| packet. Until the DCE transfers
across the DTE/DCE
interface a \fIDCE data\fR \| packet with a packet send sequence number
equal to the P(R) indicated in the \fIDTE reject\fR \| packet, the DCE
will consider the receipt of another \fIDTE reject\fR \| packet as a procedure
error and reset the logical
channel.
.bp
.PP
Additional \fIDCE data\fR \| packets pending initial transmission may follow
the retransmitted packet(s).
.PP
A \fIDTE receive not ready\fR \| situation indicated by the transmission
of an \fIRNR\fR \| packet is cleared by the transmission of a \fIDTE reject\fR
\|
packet.
.PP
The conditions under which the DCE ignores a \fIDTE reject\fR \| packet,
or considers it as a procedure error, are those described for \fIflow control\fR
\|
packets (see Annex\ C).
.RT
.sp 1P
.LP
6.5
    \fIIncoming calls barred\fR
.sp 9p
.RT
.PP
\fIIncoming calls barred\fR \| is an optional user facility agreed for
a period of time. This facility applies to all logical channels used at
the
DTE/DCE interface for virtual calls.
.PP
This user facility, if subscribed to, prevents incoming virtual calls from
being presented to the DTE. The DTE may originate outgoing virtual
calls.
.PP
\fINote\ 1\fR \ \(em\ Logical channels used for virtual calls retain their
full duplex capability.
.PP
\fINote\ 2\fR \ \(em\ Some Administrations may provide a capability that
allows a virtual call to be presented to the DTE only in cases where the
called DTE
address is the address of the calling DTE.
.RT
.sp 1P
.LP
6.6
    \fIOutgoing calls barred\fR
.sp 9p
.RT
.PP
\fIOutgoing calls barred\fR \| is an optional user facility agreed for
a period of time. This facility applies to all logical channels used at the
DTE/DCE interface for virtual calls.
.PP
This user facility, if subscribed to, prevents the DCE from accepting outgoing
virtual calls from the DTE. The DTE may receive incoming virtual
calls.
.PP
\fINote\fR \ \(em\ Logical channels used for virtual calls retain their full
duplex capability.
.RT
.sp 1P
.LP
6.7
    \fIOne\(hyway logical channel outgoing\fR
.sp 9p
.RT
.PP
\fIOne\(hyway logical channel outgoing\fR \| is an optional user facility
agreed for a period of time. This user facility, if subscribed to, restricts
the logical channel use to originating outgoing virtual calls only.
.PP
\fINote\fR \ \(em\ A logical channel used for virtual calls retains its full
duplex capability.
.PP
The rules according to which logical channel group numbers and logical
channel numbers can be assigned to one\(hyway outgoing logical channels
for
virtual calls are given in Annex\ A.
.PP
\fINote\fR \ \(em\ If all the logical channels for virtual calls are one\(hyway
outgoing at a DTE/DCE interface, the effect is equivalent to the \fIincoming\fR
\fIcalls barred\fR \| facility (see \(sc\ 6.5, particularly Note\ 2).
.RT
.sp 1P
.LP
6.8
    \fIOne\(hyway logical channel incoming\fR
.sp 9p
.RT
.PP
\fIOne\(hyway logical channel incoming\fR \| is an optional user facility
agreed for a period of time. This user facility, if subscribed to, restricts
the logical channel use to receiving incoming virtual calls only.
.PP
\fINote\fR \ \(em\ A logical channel used for virtual calls retains its full
duplex capability.
.PP
The rules according to which logical channel group numbers and logical
channel numbers can be assigned to one\(hyway incoming logical channels
for
virtual calls are given in Annex\ A.
.PP
\fINote\fR \ \(em\ If all the logical channels for virtual calls are one\(hyway
incoming at a DTE/DCE interface, the effect is equivalent to the \fIoutgoing\fR
\fIcalls barred\fR \| facility (see \(sc\ 6.6).
.bp
.RT
.sp 1P
.LP
6.9
    \fINon\(hystandard default packet sizes\fR
.sp 9p
.RT
.PP
\fINon\(hystandard default packet sizes\fR \| is an optional user facility
agreed for a period of time. This facility, if subscribed to, provides
for the selection of default packet sizes from the list of packet sizes
supported by
the Administration. Some networks may constrain the packet sizes to be
the same for each direction of data transmission across the DTE/DCE interface.
In the
absence of this facility, the default packet sizes are 128\ octets.
.PP
\fINote\fR \ \(em\ In this section, the term \*Qpacket sizes\*U refers to the
maximum user data field lengths of\fIDCE data\fR \| and \fIDTE data\fR \|
packets.
.PP
Values other than the default packet sizes may be negotiated for a
virtual call by means of the \fIflow control parameter negotiation\fR \|
facility
(see \(sc\ 6.12). Values other than the default packet sizes may be agreed
for a
period of time for each permanent virtual circuit.
.RT
.sp 1P
.LP
6.10
    \fINon\(hystandard default window sizes\fR
.sp 9p
.RT
.PP
\fINon\(hystandard default window sizes\fR \| is an optional user facility
agreed for a period of time. This facility, if subscribed to, provides
for the selection of default window sizes from the list of window sizes
supported
by the Administration. Some networks may constrain the default window sizes
to be the same for each direction of data transmission across the DTE/DCE
interface. In the absence of this facility, the default windonw sizes
are\ 2.
.PP
Values other than the default window sizes may be negotiated for a
virtual call by means of the \fIflow control parameter negotiation\fR \|
facility
(see \(sc\ 12). Values other than the default window sizes may be agreed for a
period of time for each permanent virtual circuit.
.RT
.sp 1P
.LP
6.11
    \fIDefault throughput classes assignment\fR
.sp 9p
.RT
.PP
\fIDefault throughput classes assignment\fR \| is an optional user
facility agreed for a period of time. This facility, if subscribed to,
provides for the selection of default throughput classes from the list
of throughput
classes supported by the Administration. Some networks may constrain the
default throughput classes to be the same for each direction of data
transmission. In the absence of this facility, the default throughput classes
correspond to the user class of service of the DTE (see \(sc\ 7.2.2.2)
but do not exceed the maximum throughput class supported by the network.
.PP
The default throughput classes are the maximum throughput classes
which may be associated with any virtual call at the DTE/DCE interface.
Values other than the default throughput classes may be negotiated for
a virtual call by means of the \fIthroughput class negotiation\fR \| facility
(see \(sc\ 6.13). Values other than the default throughput classes may
be agreed for a period of time
for each permanent virtual circuit.
.PP
\fINote\fR \ \(em\ Throughput characteristics and throughput class are
described in \(sc\ 4.4.2.
.RT
.sp 1P
.LP
6.12
    \fIFlow control parameter negotiation\fR
.sp 9p
.RT
.PP
\fIFlow control parameter negotiation\fR \| is an optional user facility
agreed for a period of time which can be used by a DTE for virtual calls.
This facility, if subscribed to, permits negotiation on a per call basis
of the flow control parameters. The flow control parameters considered
are the packet and window sizes at the DTE/DCE interface for each direction
of data
transmission.
.PP
\fINote\fR \ \(em\ In this section, the term \*Qpacket sizes\*U refers to the
maximum user data field lengths of \fIDCE data\fR \| and \fIDTE data\fR \|
packets.
.PP
In the absence of the \fIflow control parameter negotiation\fR \| facility,
the flow control parameters to be used at a particular DTE/DCE interface
are the default packet sizes (see \(sc\ 6.9) and the default window sizes
(see \(sc\ 6.10).
.PP
When the calling DTE has subscribed to the \fIflow control parameter\fR
\fInegotiation\fR \| facility, it may request packet sizes and/or window
sizes for
both direction of data transmission (see \(sc\(sc\ 7.2.1 and\ 7.2.2.1).
If particular window sizes are not explicitly requested in a\fIcall request\fR
\| packet, the DCE will assume that the default window sizes were requested
for both directions of data transmission. If particular packet sizes are
not explicitly requested,
the DCE will assume that the default packet sizes were requested for both
directions of data transmission.
.bp
.PP
When a called DTE has subscribed to the \fIflow control parameter\fR
\fInegotiation\fR \| facility, each \fIincoming call\fR \| packet will
indicate the packet and window sizes from which DTE negotiation can start.
No relationship needs to exist between the packet sizes (P) and window
sizes (W) requested in the \fIcall\fR \fIrequest\fR \| packet and those
indicated in the \fIincoming call\fR \| packet. The
called DTE may request window and packet sizes with facility in the \fIcall\fR
\fIaccepted\fR \| packet. The only valid facility requests in the \fIcall
accepted\fR \|
packet, as a function of the facility indications in the \fIincoming call\fR \|
packet, are given in Table\ 24/X.25. If the facility request is not made
in the \fIcall accepted\fR \| packet, the DTE is assumed to have accepted
the indicated
values (regardless of the default values) for both directions of data
transmission.
.RT
.ce
\fBH.T. [T41.25]\fR
.ce
TABLE\ 24/X.25
.ce
\fBValid facility requests in call accepted packets in response to\fR
.ce

.ce
\fBfacility indications in incoming call packets\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(114p) | cw(114p) .
Facility indication    Valid facility request
_
.T&
lw(114p) | lw(114p) .
W(indicated) \(>=" 2    T{
W(indicated) \(>=" W(requested)  2
T}
.T&
lw(114p) | lw(114p) .
W(indicated) = 1    W(requested) = 1 or 2
_
.T&
lw(114p) | lw(114p) .
P(indicated) \(>=" 128    T{
P(indicated) \(>=" P(requested) \*(>= 128
T}
.T&
lw(114p) | lw(114p) .
P(indicated) < 128    T{
128 \(>=" P(requested) \*(>=icated)
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 24/X.25 [T41.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
When the calling DTE has subscribed to the \fIflow control\fR
\fIparameter negotiation\fR \| facility, every \fIcall connected\fR \|
packet will indicate the packet and window sizes to be used at the DTE/DCE
interface for the call. The only valid facility indications in the \fIcall
connected\fR \| packet, as a
function of the facility requests in the \fIcall request\fR \| packet,
are given in Table\ 25/X.25.
.ce
\fBH.T. [T42.25]\fR
.ce
TABLE\ 25/X.25
.ce
\fBValid facility indications in call connected packets in response to\fR
.ce

.ce
\fBfacility requests in call request packets\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(114p) | cw(114p) .
Facility indication    Valid facility request
_
.T&
lw(114p) | lw(114p) .
W(requested) \(>=" 2    T{
W(requested) \(>=" W(indicated) \(*>= 2
T}
.T&
lw(114p) | lw(114p) .
W(requested) = 1    W(indicated) = 1 or 2
_
.T&
lw(114p) | lw(114p) .
P(requested) \(>=" 128    T{
P(requested) \(>=" P(indicated) \(*>= 128
T}
.T&
lw(114p) | lw(114p) .
P(requested) < 128    T{
128 \(>=" P(indicated) \(*>= P(requested)
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 25/X.25 [T42.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The network may have constraints requiring the flow control
parameters used for a call to be modified before indicating them to the
DTE in the \fIincoming call\fR \| packet or \fIcall connected\fR \| packet;
e.g.,\ the ranges of
parameter values available on various networks may differ.
.PP
Window and packet sizes need not be the same at each end of a virtual  call.
.PP
The role of the DCE in negotiating the flow control parameters may be network
dependent.
.RT
.sp 1P
.LP
6.13
    \fIThroughput class negotiation\fR
.sp 9p
.RT
.PP
\fIThroughput class negotiation\fR \| is an optional user facility agreed
for a period of time which can be used by a DTE for virtual calls. This
facility, if subscribed to, permits negotiation on a per call basis of the
throughput classes. The throughput classes are considered independently for
each direction of data transmission.
.PP
Default values are agreed between the DTE and the Administration (see \(sc\
6.11). The default values correspond to the maximum throughput classes
which may be associated with any virtual call at the DTE/DCE interface.
.PP
When the calling DTE has subscribed to the \fIthroughput class\fR \|
negotiation facility, it may request the throughput classes of the virtual
call in the \fIcall request\fR \| packet for both directions of data transmission
(see
\(sc\(sc\ 7.2.1 and\ 7.2.2.2). If particular throughput classes are not
explicitly
requested, the DCE will assume that the default values were requested for
both directions of data transmission.
.PP
When a called DTE has subscribed to the \fIthroughput class\fR
\fInegotiation\fR \| facility, each \fIincoming call\fR \| packet will
indicate the
throughput classes from which DTE negotiation may start. These throughput
classes are lower or equal to the ones selected at the calling DTE/DCE
interface, either explicitly, or by default if the calling DTE has not
subscribed to the \fIthroughput class negotiation\fR facility or not
explicitly requested throughput class values in the \fIcall request\fR
\| packet.
These throughput classes indicated to the called DTE will also not be higher
than the default throughput classes, respectively for each direction of data
transmission, at the calling and the called DTE/DCE interfaces. They may be
further constrained by internal limitations of the network.
.PP
The called DTE may request with a facility in the \fIcall accepted\fR \|
packet throughput classes that should finally apply to the virtual call.
The only valid throughput classes in the \fIcall accepted\fR \| packet
are lower than or equal to the ones (respectively) indicated in the \fIincoming
call\fR \| packet. If the called DTE does not make any throughput class
facility request in the
\fIcall accepted\fR \| packet, the throughput classes finally applying
to the virtual call will be the ones indicated in the \fIincoming call\fR
\| packet.
.PP
If the called DTE has not subscribed to the \fIthroughput class\fR
\fInegotiation\fR \| facility, the throughput classes finally applying
to the virtual call are less than or equal to the ones selected at the
calling DTE/DCE
interface, and less than or equal to the default values defined at the
called DTE/DCE interface.
.PP
When the calling DTE has subscribed to the \fIthroughput class\fR
\fInegotiation\fR \| facility, every \fIcall connected\fR \| packet will
indicate the
throughput classes finally applying to the virtual call.
.PP
When neither the calling DTE nor the called DTE has subscribed to the \fIthroughput
class negotiation\fR \| facility, the throughput classes applying to
the virtual call will not be higher than the ones agreed as defaults at the
calling and called DTE/DCE interfaces. They may be further constrained
to lower values by the network, e.g.,\ for international service.
.PP
\fINote\ 1\fR \ \(em\ Since both \fIthroughput class negotiation\fR \| and
\fIflow control parameter negotiation\fR \| (see \(sc\ 6.12) facilities
can be applied to a single call, the achievable throughput will depend
on how users manipulate
the D\ bit.
.PP
\fINote\ 2\fR \ \(em\ Users are cautioned that the choice of too small
a window and packet size of a DTE/DCE interface (made by use of the \fIflow
control\fR
\fIparameter negotiation\fR \| facility may adversely affect the attainable
throughput class of a virtual call. This is likewise true of flow control
mechanisms adopted by the DTE to control data transmission from the
DCE.
.bp
.RT
.sp 1P
.LP
6.14
    \fIClosed user group related facilities\fR
.sp 9p
.RT
.PP
A set of closed user group (CUG) optional user facilities enables users
to form groups of DTEs to and/or from which access is restricted.
Different combinations of access restrictions to and/or from DTEs having
one or more of these facilities result in various combinations of
accessibility.
.PP
A DTE may belong to one or more CUGs. Each DTE belonging to at least one
CUG has either the \fIclosed user group\fR \| facility (see \(sc\ 6.14.1)
or one or both of the \fIclosed user group with outgoing access\fR \| and
the
\fIclosed user group with incoming access\fR \| facilities (see \(sc\(sc\
6.14.2
and\ 6.14.3). For each CUG to which a DTE belongs, either none of the
\fIincoming calls barred within a closed user group\fR \| or the \fIoutgoing
calls\fR
\fIbarred within a closed user group\fR \| facilities (see \(sc\(sc\ 6.14.4
and 6.14.5) may apply for that DTE. Different combinations of CUG facilities
may apply for
different DTEs belonging to the same CUG.
.PP
When a DTE belonging to one or more CUGs places a virtual call, the
DTE may explicitly indicate in the \fIcall request\fR \| packet the CUG
selected by using the \fIclosed user group selection\fR \| facility (see
\(sc\ 6.14.6) or the
\fIclosed user group with outgoing access selection\fR \| facility (see
\(sc\ 6.14.7)
(see Note). When a DTE belonging to one or more CUGs receives a virtual
call, the CUG selected may be explicitly indicated in the \fIincoming call\fR
\| packet
through the use of the \fIclosed user group selection\fR \| facility or
the \fIclosed\fR \fIuser group with outgoing access selection\fR \| facility.
.PP
\fINote\fR \ \(em\ For a given virtual call, only one of the above\(hymentioned
selection facilities can be present.
.PP
The number of CUGs to which a DTE can belong is network
dependent.
.RT
.sp 1P
.LP
6.14.1
    \fIClosed user group\fR
.sp 9p
.RT
.PP
\fIClosed user group\fR \| is an optional user facility agreed for a
period of time for virtual calls. This user facility, if subscribed to,
enables the DTE to belong to one or more closed user groups. A closed user
group
permits the DTEs belonging to the group to communicate with each other but
precludes communication with all other DTEs.
.PP
When the DTE belongs to more than one closed user group, a
preferential closed user group must be specified.
.RT
.sp 1P
.LP
6.14.2
    \fIClosed user group with outgoing access\fR
.sp 9p
.RT
.PP
\fIClosed user group with outgoing access\fR \| is an optional user
facility agreed for a period of time for virtual calls. This user facility,
if subscribed to, enables the DTE to belong to one or more closed user
groups (as in \(sc\ 6.14.1) and to originate virtual calls to DTEs in the
open part of the
network (i.e.,\ DTEs not belonging to any closed user group) and to DTEs
belonging to other CUGs with the incoming access capability.
.PP
When the \fIclosed user group with outgoing access\fR \| facility is
subscribed to and the DTE has a preferential CUG, then only the
\fIclosed user group selection\fR \| facility (as in \(sc\ 6.14.6) is applicable
for use at the interface.
.PP
When the \fIclosed user group with outgoing access\fR \| facility is
subscribed to and the network offers to the DTE the capability of choosing
whether or not to have a preferential CUG (i.e.,\ the \fIclosed user group
with\fR \fIoutgoing access selection\fR \| facility (see \(sc\ 6.14.7)
is offered by the
network), and the DTE has no preferential CUG, then both the \fIclosed user\fR
\fIgroup selection\fR \| and the \fIclosed user group with outgoing access
selection\fR \| facilities are applicable for use at the interface.
.RT
.sp 1P
.LP
6.14.3
    \fIClosed user group with incoming access\fR
.sp 9p
.RT
.PP
\fIClosed user group with incoming access\fR \| is an optional user
facility agreed for a period of time for virtual calls. This user facility,
if subscribed to, enables the DTE to belong to one or more closed user
groups (as in \(sc\ 6.14.1) and to receive incoming calls from DTEs in
the open part part of the network (i.e., DTEs not belonging to any closed
user group) and from DTEs belonging to other CUGs with the outgoing access
capability.
.PP
When the \fIclosed user group with incoming access\fR \| facility is
subscribed to and the DTE has a preferential CUG, then only the \fIclosed
user\fR \fIgroup selection\fR \| facility is applicable for use at the
interface.
.bp
.PP
When the \fIclosed user group with incoming access\fR \| facility is
subscribed to and the network offers to the DTE the capability of choosing
whether or not to have a preferential CUG (i.e.,\ the \fIclosed user group
with\fR \fIoutgoing access selection\fR \| facility is offered by the network),
and the DTE has no preferential CUG, then both the \fIclosed user group
selection\fR \| and the \fIclosed user group with outgoing access selection\fR
\| facilities are applicable for use at the interface.
.RT
.sp 1P
.LP
6.14.4
    \fIIncoming calls barred within a closed user group\fR
.sp 9p
.RT
.PP
\fIIncoming calls barred within a closed user group\fR \| is an optional
user facility agreed for a period of time. This user facility, if subscribed
to for a given closed user group, permits the DTE to originate virtual
calls to
DTEs in this closed user group, but precludes the reception of incoming
calls from DTEs in this closed user group.
.RT
.sp 1P
.LP
6.14.5
    \fIOutgoing calls with barred within a closed user group\fR
.sp 9p
.RT
.PP
\fIOutgoing calls barred within a closed user group\fR \| is an optional
user facility agreed for a period of time. This user facility, if subscribed
for a given closed user group, permits the DTE to receive virtual calls from
DTEs in this closed user group, but prevents the DTE from originating virtual
calls to DTEs in this closed user group.
.RT
.sp 1P
.LP
6.14.6
    \fIClosed user group selection\fR
.sp 9p
.RT
.PP
\fIClosed user group selection\fR \| is an optional user facility which
may be used on a per virtual call basis. This facility may be requested
or
received by a DTE only if it has subscribed to the \fIclosed user group\fR \|
facility, or the \fIclosed user group with outgoing access\fR \| facility
and/or the \fIclosed user group with incoming access\fR \| facility.
.PP
The \fIclosed user group selection\fR \| facility (see \(sc\(sc\ 7.2.1
and 7.2.2.3) may be used by the calling DTE in the \fIcall request\fR \|
packet to specify the
closed user group selected for a virtual call.
.PP
The \fIclosed user group selection\fR \| facility is used in the \fIincoming\fR
\fIcall\fR \| packet to indicate to the called DTE the closed user group
selected for a virtual call.
.PP
The number of closed user groups to which a DTE can belong is network dependent.
If the maximum value of the index assigned for use by the DTE to
select the closed user group is\ 99 or less, the basic format of the \fIclosed\fR
\fIuser group selection\fR \| facility must be used. If the maximum value
of the
index assigned is between\ 100 and\ 9999, the extended format of the
\fIclosed user group selection\fR \| facility must be used.
.PP
Some networks may permit a DTE to use either the basic or extended
format of the \fIclosed user group selection\fR \| facility when the index
is\ 99 or less.
.PP
\fINote\fR \ \(em\ When a DTE subscribes to less than 101 closed user groups,
the network should be able to agree on a maximum value of the index smaller
than\ 100 if requested by the DTE.
.PP
The appearance in a \fIcall request\fR \| packet of both formats, or a
format inconsistent with the number of CUGs subscribed to, will be treated
as a facility code not allowed.
.PP
The significance of the \fIclosed user group selection\fR \| facility in
\fIcall request\fR \| packets is given in Table\ 26/X.25 and in \fIincoming
call\fR \|
packets is given in Table\ 27/X.25.
.RT
.sp 1P
.LP
6.14.7
    \fIClosed user group with outgoing access selection\fR
.sp 9p
.RT
.PP
\fIClosed user group with outgoing access selection\fR \| is an optional
user facility which may be used on a per virtual call basis. This facility
may be requested by a DTE only if the network supports it and the DTE has
subscribed to the \fIclosed user group with outgoing access\fR \| facility
or to both the \fIclosed user group with outgoing access\fR \| and \fIclosed
user group with\fR
\fIincoming access\fR \| facilities. This facility may be received by a
DTE only if the network supports it and the DTE has subscribed to the \fIclosed
user group\fR \fIwith incoming access\fR \| facility or to both the \fIclosed
user group with\fR
\fIincoming access\fR \| and \fIclosed user group with outgoing access\fR \|
facilities.
.PP
The \fIclosed user group with outgoing access selection\fR \| facility
(see \(sc\(sc\ 7.2.1 and 7.2.2.4) may be used by the calling DTE in the
\fIcall request\fR \|
packet to specify the closed user group selected for a virtual call and to
indicate that outgoing access is also desired.
.bp
.RT
.ce
\fBH.T. [T43.25]\fR
.ce
TABLE\ 26/X.25
.ce
\fBMeaning of closed user group facilities\fR
.ce
\fBin call request packets\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(66p) | cw(48p) | cw(48p) | cw(66p) .
T{
Contents of \fIcall\fR
\fIrequest\fR
packet
(see Note 2)
Closed user
group subscription
of the calling DTE
(see Note 1)
T}    T{
\fIClosed user group selection\fR
facility
T}    T{
\fIClosed user group with outgoing access selection\fR
facility
T}    T{
Neither \fIclosed user group selection\fR
nor \fIclosed user group with\fR
\fIoutgoing access selection\fR
facility
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
T{
CUG with preferential
(see Note 3)
T}    CUG specified  (see Note 4)    Not allowed  (call cleared)    T{
Preferential or only CUG
(see Note 4)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/IA with preferential    CUG specified  (see Note 4)    Not allowed  (call cleared)    T{
Preferential or only CUG
(see Note 4)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/OA with preferential    T{
CUG specified + outgoing access
(see Note 4)
T}    Not allowed  (call cleared)    T{
Preferential or only CUG + outgoing access (see Notes 5, 6)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/IA/OA with preferential    T{
CUG specified + outgoing access
(see Note 4)
T}    Not allowed  (call cleared)    T{
Preferential or only CUG + outgoing access (see Notes 5, 6)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/IA without preferential    CUG specified  (see Note 4)    Not allowed  (call cleared)    Not allowed (call cleared)
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/OA without preferential    CUG specified  (see Note 4)    T{
CUG specified + outgoing access
(see Notes 5, 6)
T}    Outgoing access
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
T{
CUG/IA/OA without preferential
T}    CUG specified  (see Note 4)    T{
CUG specified + outgoing access
(see Notes 5, 6)
T}    Outgoing access
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
No CUG    Not allowed  (call cleared)    Not allowed  (call cleared)    T{
Outgoing access
OA:\ Outgoing access
.line
IA:\ \ Incoming access
.parag
\fINote\ 1\fR
\ \(em\ The order of subscription types is different from that in
Table 27/X.25.
.parag
\fINote\ 2\fR
\ \(em\ The inclusion of both the \fIclosed user group selection\fR
\| facility and the \fIclosed user group with outgoing access selection\fR
facility is not
allowed in the \fIcall request\fR
packet.
.parag
\fINote\ 3\fR
\ \(em\ CUG without preferential is not allowed.
.parag
\fINote\ 4\fR
\ \(em\ If outgoing calls are barred within the specified CUG or within
the preferential or only CUG, then the call is cleared.
.parag
\fINote\ 5\fR
\ \(em\ If outgoing calls are barred within the specified CUG or within
the preferential or only CUG, then only outgoing access applies.
.parag
\fINote\ 6\fR
\ \(em\ For international calls, if the destination network does not
support the \fIclosed user group with outgoing access selection\fR
facility,
the call may be cleared even if the called DTE belongs to the
specified closed user group or to the open world or has
incoming access.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 26/X.25 [T43.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T44.25]\fR
.ce
TABLE\ 27/X.25
.ce
\fBMeaning of closed user group facilities\fR
.ce
\fBin incoming call packets\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(66p) | cw(48p) | cw(48p) | cw(66p) .
T{
Contents of \fIincoming\fR
\fIcall\fR
packet
Closed user
group subscription
of the called DTE
(see Note 1)
T}    T{
\fIClosed user group selection\fR
facility
T}    T{
\fIClosed user group with outgoing access selection\fR
facility
T}    T{
Neither \fIclosed user group selection\fR
nor \fIclosed user group with\fR
\fIoutgoing access selection\fR
facility
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
T{
CUG with preferential
(see Note 2)
T}    CUG specified  (see Note 3)    Not applicable    T{
Preferential or only CUG
(see Note 3)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/OA with preferential    CUG specified  (see Note 3)    Not applicable    T{
Preferential or only CUG
(see Note 3)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/IA with preferential    T{
CUG specified + incoming access
(see Note 4)
T}    Not applicable    T{
Preferential or only CUG + incoming access (see Note 5)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/IA/OA with preferential    T{
CUG specified + incoming access
(see Note 4)
T}    Not applicable    T{
Preferential or only CUG + incoming access (see Note 5)
T}
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/OA without preferential    CUG specified  (see Note 3)    Not applicable    Not applicable
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
CUG/IA without preferential    CUG specified  (see Note 3)    T{
CUG specified + incoming access
(see Note 4)
T}    Incoming access
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
T{
CUG/IA/OA without preferential
T}    CUG specified  (see Note 3)    T{
CUG specified + incoming access
(see Note 4)
T}    Incoming access
_
.T&
lw(66p) | cw(48p) | cw(48p) | lw(66p) .
No CUG    Not applicable    Not applicable    T{
Incoming access
OA:\ Outgoing access
.line
IA:\ Incoming access
.parag
\fINote\ 1\fR
\ \(em\ The order of subscription types is different from that in
Table 26/X.25.
.parag
\fINote\ 2\fR
\ \(em\ CUG without preferential is not allowed.
.parag
\fINote\ 3\fR
\ \(em\ When incoming calls are barred within this CUG,
the call is blocked; there is no incoming call.
.parag
\fINote\ 4\fR
\ \(em\ When incoming calls are barred within this CUG, only incoming
access applies and the \fIincoming call\fR
packet carries neither the \fIclosed\fR
\fIuser group selection\fR
nor the \fIclosed user group with outgoing access\fR
\fIselection\fR
facility.
.parag
\fINote\ 5\fR
\ \(em\ When incoming calls are barred within this CUG, only incoming
access applies.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 27/X.25 [T44.25], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The \fIclosed user group with outgoing access selection\fR \| facility is
used in the \fIincoming call\fR \| packet to indicate to the called DTE
the closed
user group selected for a virtual call and that outgoing access had applied
at the calling DTE.
.PP
The \fIclosed user group with outgoing access selection\fR \| facility
can only be present in the facility field of \fIcall set\(hyup\fR \| packets
if the DTE does not have a preferential closed user group.
.PP
The number of closed user groups to which a DTE can belong is network dependent.
If the maximum value of the index assigned for use by the DTE to
select the closed user group is\ 99 or less, the basic format of the \fIclosed\fR
\fIuser group with outgoing access selection\fR \| facility must be used.
If the
maximum value of the index assigned is between\ 100 and\ 9999, the extended
format of the \fIclosed user group with outgoing access selection\fR \|
facility must be used.
.PP
Some networks may permit a DTE to use either the basic or extended
format of the \fIclosed user group with outgoing access selection\fR \|
facility when the index is\ 99 or less.
.PP
\fINote\fR \ \(em\ When a DTE subscribes to less than 101 closed user groups,
the network should be able to agree to a maximum value of the index smaller
than\ 100 if requested by the DTE.
.PP
The appearance in a \fIcall request\fR \| packet of both formats or a format
inconsistent with the number of CUGs subscribed to will be treated as a
facility code not allowed.
.PP
The significance of the presence of the \fIclosed user group with\fR
\fIoutgoing access selection\fR \| facility in \fIcall request\fR \| packets
is given in
Table\ 26/X.25 and in \fIincoming call\fR \| packets is given in
Table\ 27/X.25.
.RT
.sp 1P
.LP
6.14.8
    \fIAbsence of both CUG selection facilities\fR
.sp 9p
.RT
.PP
The significance of the absence of both the \fIclosed user group\fR
\fIselection\fR \| facility and the \fIclosed user group with outgoing
access\fR
\fIselection\fR \| facility in call request packets is given in Table\
26/X.25 and in \fIincoming call\fR \| packets is given in Table\ 27/X.25.
.RT
.sp 1P
.LP
6.15
    \fIBilateral closed user group related facilities\fR
.sp 9p
.RT
.PP
The set of bilateral closed user group (BCUG) optional user
facilities enables pairs of DTEs to form bilateral relations allowing access
between each other while excluding access to or from other DTEs with which
such a relation has not been formed. Different combinations of access
restrictions for DTEs having these facilities result in various combinations
of accessibility.
.PP
A DTE may belong to one or more BCUGs. Each DTE belonging to at least one
BCUG has either the \fIbilateral closed user group\fR \| facility (see
\(sc\ 6.15.1) or the \fIbilateral closed user group with outgoing access\fR
\| facility (see
\(sc\ 6.15.2). For a given BCUG, it is permissible for one DTE to subscribe
to the \fIbilateral closed user group\fR \| facility while the other DTE
subscribes to the \fIbilateral closed user group with outgoing access\fR
\| facility.
.PP
When a DTE belonging to one or more BCUGs places a virtual call, the DTE
should indicate in the \fIcall request\fR \| packet the BCUG selected by
using
the \fIbilateral closed user group selection\fR \| facility (see \(sc\
6.15.3). When a
DTE belonging to one or more BCUGs receives a virtual call, the BCUG selected
will be indicated in the \fIincoming call\fR \| packet through the use
of the
\fIbilateral closed user group selection\fR \| facility.
.PP
The number of BCUGs to which a DTE can belong is network
dependent.
.RT
.sp 1P
.LP
6.15.1
    \fIBilateral closed user group\fR
.sp 9p
.RT
.PP
\fIBilateral closed user group\fR \| is an optional user facility agreed
for a period of time for virtual calls. This facility, if subscribed to,
enables
the DTE to belong to one or more bilateral closed user groups. A bilateral
closed user group permits a pair of DTEs who bilaterally agree to communicate
with each other to do so, but precludes communication with all other
DTEs.
.RT
.sp 1P
.LP
6.15.2
    \fIBilateral closed user group with outgoing access\fR
.sp 9p
.RT
.PP
\fIBilateral closed user group with outgoing access\fR \| is an optional
user facility agreed for a period of time for virtual calls. This facility,
if subscribed to, enables the DTE to belong to one or more bilateral closed
user groups (as in \(sc\ 6.15.1) and to originate virtual calls to DTEs
in the open part of the network (i.e.,\ DTEs not belonging to any bilateral
closed user
group).
.bp
.RT
.sp 1P
.LP
6.15.3
    \fIBilateral closed user group selection\fR
.sp 9p
.RT
.PP
\fIBilateral closed user group selection\fR \| is an optional user
facility which may be used on a per virtual call basis. This facility should
be requested or will only be received by a DTE if it has subscribed to
the
\fIbilateral closed user group\fR \| facility (see \(sc\ 6.15.1), or the
\fIbilateral\fR
\fIclosed user group with outgoing access\fR \| facility
(see \(sc\ 6.15.2).
.PP
The \fIbilateral closed user group selection\fR \| facility (see \(sc\(sc\
7.2.1
and\ 7.2.2.5) is used by the calling DTE in the \fIcall request\fR \| packet to
specify the bilateral closed user group selected for a virtual call. The
called DTE address length shall be coded all zeros.
.PP
The \fIbilateral closed user group selection\fR \| facility is used in
the \fIincoming call\fR \| packet to indicate to the called DTE, the bilateral
closed
user group selected for a virtual call. The calling DTE address length
will be coded all zeros.
.RT
.sp 1P
.LP
6.16
    \fIFast select\fR
.sp 9p
.RT
.PP
\fIFast select\fR \| is an optional user facility which may be requested
by a DTE for a given virtual call.
.PP
DTEs can request the \fIfast select\fR \| facility on a per call basis by
means of an appropriate facility request (see \(sc\(sc\ 7.2.1 and\ 7.2.2.6)
in a
\fIcall request\fR \| packet using any logical channel which has been assigned
to
virtual calls.
.PP
The \fIfast select\fR \| facility, if requested in the \fIcall request\fR \|
packet and if it indicates no restriction on response, allows this packet to
contain a call user data field of up to 128\ octets, authorizes the DCE to
transmit to the DTE, during the \fIDTE waiting\fR state, a \fIcall connected\fR
or
\fIclear indication\fR packet with a called or clear user data field respectively
of up
to 128\ octets, and authorizes the DTE and the DCE to transmit after the
call is connected, a \fIclear request\fR \| or a \fIclear indication\fR
\| packet, respectively,
with a clear user data field of up to 128\ octets.
.PP
The \fIfast select\fR \| facility, if requested in the \fIcall request\fR \|
packet and if it indicates restriction on response, allows this packet to
contain a call user data field of up to 128\ octets and authorizes the DCE to
transmit to the DTE, during the \fIDTE waiting\fR \| state, a \fIclear
indication\fR \|
packet with a clear user data field of up to 128\ octets; the DCE would
not be authorized to transmit a \fIcall connected\fR \| packet.
.PP
When a DTE requests the \fIfast select\fR \| facility in a \fIcall request\fR
\| packet, the \fIincoming call\fR \| packet should only be delivered to
the called DTE if that DTE has subscribed to the \fIfast select acceptance\fR
\| facility (see
\(sc\ 6.17).
.PP
If the called DTE has subscribed to the \fIfast select acceptance\fR \|
facility, it will be advised that the \fIfast select\fR \| facility, and an
indication of whether or not there is a restriction on the response, has
been requested through the inclusion of the appropriate facility (see \(sc\(sc\
7.2.1
and\ 7.2.2.6) in the \fIincoming call\fR \| packet.
.PP
If the called DTE has not subscribed to the \fIfast select acceptance\fR
\| facility, an \fIincoming call\fR \| packet with the \fIfast select\fR
\| facility
requested will not be transmitted and a \fIclear indication\fR \| packet
with the
cause \*QFast select acceptance not subscribed\*U will be returned to the
calling DTE.
.PP
The presence of the \fIfast select\fR \| facility indicating no restriction
on response in an \fIincoming call\fR \| packet permits the DTE to issue
as a direct response to this packet a \fIcall accepted\fR \| or \fIclear
request\fR \| packet with a
called or clear user data field, respectively, of up to 128\ octets. If
the call is connected, the DTE and the DCE are then authorized to transmit
a \fIclear\fR
\fIrequest\fR \|or a \fIclear indication\fR \| packet, respectively, with
a clear user
data field of up to 128\ octets.
.PP
The presence of the \fIfast select\fR \| facility indicating restriction
on response in an \fIincoming call\fR \| packet permits the DTE to issue
as a direct
response to this packet a \fIclear request\fR \| packet with a clear user
data field of up to 128\ octets; the DTE would not be authorized to send
a \fIcall accepted\fR \| packet.
.PP
\fINote\fR \ \(em\ The call user data field, the called user data field
and the clear user data field will not be fragmented for delivery across
the DTE/DCE
interface.
.bp
.PP
The significance of the \fIcall connected\fR \| packet or the \fIclear\fR
\fIindication\fR \| packet with the cause \*QDTE originated\*U as a direct
response to
the \fIcall request\fR \| packet with the \fIfast select\fR \| facility
is that the
\fIcall request\fR \| packet with the data field has been received by the
called
DTE.
.PP
All other procedures of a call in which the \fIfast select\fR \| facility
has been requested are the same as those of a virtual call.
.RT
.sp 1P
.LP
6.17
    \fIFast select acceptance\fR
.sp 9p
.RT
.PP
\fIFast select acceptance\fR \| is an optional user facility agreed for
a period of time. This user facility, if subscribed to, authorizes the
DCE to
transmit to the DTE incoming calls which request the \fIfast select\fR
\| facility. In the absence of this facility, the DCE will not transmit
to the DTE incoming calls which request the \fIfast select\fR \| facility.
.RT
.sp 1P
.LP
6.18
    \fIReverse charging\fR
.sp 9p
.RT
.PP
\fIReverse charging\fR \| is an optional user facility which may be
requested by a DTE for a given virtual call (see \(sc\(sc\ 7.2.1
and\ 7.2.2.6).
.RT
.sp 1P
.LP
6.19
    \fIReverse charging acceptance\fR
.sp 9p
.RT
.PP
\fIReverse charging acceptance\fR \| is an optional user facility agreed
for a period of time for virtual calls. This user facility, if subscribed
to, authorizes the DCE to transmit to the DTE incoming calls which request
the
\fIreverse charging\fR \| facility. In the absence of this facility, the
DCE will not transmit to the DTE incoming calls which request the \fIreverse
charging\fR \|
facility.
.RT
.sp 1P
.LP
6.20
    \fILocal charging prevention\fR
.sp 9p
.RT
.PP
\fILocal charging prevention\fR \| is an optional user facility agreed
for a period of time for virtual calls. This user facility, when subscribed
to, authorizes the DCE to prevent the establishment of virtual calls which
the
subscriber must pay for by:
.RT
.LP
    a)
    not transmitting to the DTE incoming calls which request
the \fIreverse charging\fR \| facility, and
.LP
    b)
    ensuring that the charges are made to another party whenever
a call is requested by the DTE. This other party can be
determined by using any of a number of actions, both
procedural and administrative. The procedural methods
include:
.LP
    \(em
    the user of reverse charging,
.LP
    \(em
    identification of a third party using
\fINUI subscription\fR \| facility (see \(sc\ 6.21.1) and
\fINUI selection\fR \| facility (see \(sc\ 6.21.3).
.PP
When the party to be charged has not been established for a call request,
the DCE that receives the \fIcall request\fR \| packet will apply reverse
charging to this call.
.PP
\fINote\fR \ \(em\ For an interim period of time, some networks may choose to
enforce local charging prevention by clearing the call when the party to be
charged has not been established.
.RT
.sp 1P
.LP
6.21
    \fINetwork user identification (NUI) related facilities\fR
.sp 9p
.RT
.PP
The set of network user identification (NUI) related facilities
enables the DTE to provide information to the network for purposes of billing,
security, network management, or to invoke subscribed facilities.
.PP
This set is composed of three optional user facilities, \fINUI\fR
\fIsubscription\fR \| facility (see \(sc\ 6.21.1) and \fINUI override\fR
\| facility (see
\(sc\ 6.21.2) may be agreed for a period of time for virtual calls. A DTE may
subscribe to one or both of these facilities. When one or both of these
facilities are subscribed to, one or several network user identifiers are
also agreed for a period of time. A given network user identifier may be
either
specific or common to \fINUI subscription\fR \| facility and \fINUI override\fR
\|
facility. The network user identifier is transmitted by the DTE to the DCE
in the \fINUI selection\fR \| facility (see \(sc\ 6.21.3).
.bp
.PP
Network user identifier is never transmitted to the remote DTE. The
calling DTE address transmitted to the remote DTE in the calling DTE address
field should not be inferred from the network user identifier transmitted by
the DTE in the \fINUI selection\fR \| facility in the \fIcall request\fR \|
packet.
.RT
.sp 1P
.LP
6.21.1
    \fINUI subscription\fR
.sp 9p
.RT
.PP
\fINUI subscription\fR \| is an optional user facility agreed for a
period of time for virtual calls. This facility, if subscribed to, enables
the DTE to provide information to the network for billing, security or
network
management purposes on a per call basis. This information may be provided by
the DTE in the \fIcall request\fR \| packet or in the \fIcall accepted\fR
\| packet by
using the \fINUI selection\fR \| facility (see \(sc\ 6.21.3). It may be
used whether or not the DTE has also subscribed to the \fIlocal charging
prevention\fR \|
facility (see \(sc\ 6.20). If the DCE determines that the network user
identifier is invalid or that the \fINUI selection\fR \| facility is not
present when
required by the network, it will clear the call as described in
Annex\ C.
.RT
.sp 1P
.LP
6.21.2
    \fINUI override\fR
.sp 9p
.RT
.PP
\fINUI override\fR \| is an optional user facility agreed for a period
of time for virtual calls. When this facility is subscribed to, one or
more
network user identifiers are also agreed for a period of time. Associated
with each network user identifier is a set of subscription\(hytime optional
user
facilities. When one of these network user identifiers is provided in a
\fIcall\fR \fIrequest\fR \| packet by means of the \fINUI selection\fR
\| facility (see \(sc\ 6.21.3), the set of subscription\(hytime optional
user facilities associated with it overrides the facilities which apply
to the interface. This override does not apply to
other existing calls or subsequent calls on the interface. It remains in
effect for the duration of the particular call to which it applies.
.PP
The optional user facilities that may be associated with a network
user identifier when the \fINUI override\fR \| facility has been subscribed
to are
specified in Annex\ H. The optional user facilities which have been agreed
for a period of time for the interface and which are not overriden by using
the
\fINUI override\fR \| facility remain in effect.
.RT
.sp 1P
.LP
6.21.3
    \fINUI selection\fR
.sp 9p
.RT
.PP
\fINUI selection\fR \| is an optional user facility which may be
requested by a DTE for a given virtual call (see \(sc\(sc\ 7.2.1 and\ 7.2.2.7).
This
user facility may be requested by a DTE only if it has subscribed to the
\fINUI subscription\fR \| facility (see \(sc\ 6.21.1) and/or the \fINUI
override\fR \|
facility. \fINUI selection\fR \| facility permits the DTE to specify which
network
user identifier is to be used in conjunction with the \fINUI subscription\fR \|
facility and/or the \fINUI override\fR \| facility.
.PP
\fINUI selection\fR \| may be requested in a \fIcall request\fR \| packet
if the selected network user identifier has been agreed in conjunction
with the
\fINUI subscription\fR \| facility or the \fINUI override\fR \| facility.
\fINUI selection\fR \| may be requested in the \fIcall accepted\fR \| packet
if the selected network user
identifier has been agreed in conjunction with the \fINUI subscription\fR \|
facility.
.PP
Some networks may require that the \fINUI selection\fR \| facility be
requested by the DTE in every \fIcall request\fR \| packet and, possibly, in
every \fIcall accepted\fR \|packet transmitted on a given DTE/DCE interface,
when
the \fINUI subscription\fR \| facility has been agreed for a period of
time for the interface.
.PP
If the network determines that the network user identifier is invalid or
that any of the optional user facilities requested in the \fIcall request\fR
\|
packet are not allowed for the DTE, it will clear the call.
.RT
.sp 1P
.LP
6.22
    \fICharging information\fR
.sp 9p
.RT
.PP
\fICharging information\fR \| is an optional user facility which may be
either agreed for a period of time or requested by a DTE for a given virtual
call.
.PP
If the DTE is the DTE to be charged, the DTE can request the
\fIcharging information\fR \| facility on a per call basis by means of
an appropriate facility request (see \(sc\(sc\ 7.2.1 and\ 7.2.2.8.1) in
a \fIcall request\fR \| packet or
\fIcall accepted\fR \| packet.
.bp
.PP
If a DTE subscribes to the \fIcharging information\fR \| for a contractual
period, the facility is in effect for the DTE, whenever the DTE is the
DTE to be charged, without sending the facility request in \fIcall request\fR
\| or
\fIcall accepted\fR \| packets.
.PP
Using the \fIclear indication\fR \| or \fIDCE clear confirmation\fR \|
packet, the DCE will send to the DTE information about the charge for that
call and/or
other information which makes it possible for the user to calculate the
charge.
.RT
.sp 1P
.LP
6.23
    \fIRPOA related facilities\fR
.sp 9p
.RT
.PP
The set of RPOA optional user facilities provides for the calling DTEs
designation of a sequence of one or more RPOA transit network(s) within
the originating country through which the call is to be routed when more
than one RPOA transit network exists at a sequence of one or more gateways.
In
the case of international calls, this capability includes the selection
of an international RPOA in the originating country.
.RT
.sp 1P
.LP
6.23.1
    \fIRPOA subscription\fR
.sp 9p
.RT
.PP
\fIRPOA subscription\fR \| is an optional user facility agreed for a
period of time for virtual calls. This user facility, if subscribed to,
applies (unless overriden for a single virtual call by the \fIRPOA selection\fR
\| facility) to all virtual calls where more than one RPOA transit network
exist at a
sequence of one or more gateways. The \fIRPOA subscription\fR \| facility
provides a sequence of RPOA transit networks through which calls are to
be routed. In the absence of both the \fIRPOA subscription\fR \| facility
and the \fIRPOA selection\fR \|
facility (see \(sc\ 6.23.2), no user designation of RPOA transit networks is in
effect.
.RT
.sp 1P
.LP
6.23.2
    \fIRPOA selection\fR
.sp 9p
.RT
.PP
\fIRPOA selection\fR \| is an optional user facility which may be
requested by a DTE for a given virtual call (see \(sc\(sc\ 7.2.1 and 7.2.2.9).
It is not necessary to subscribe to the \fIRPOA subscription\fR \| facility
in order to use this facility. This facility, when used for a given virtual
call, applies for this virtual call only where more than one RPOA transit
network exist at a
sequence of one or more gateways. The \fIRPOA selection\fR \| facility
provides a
sequence of RPOA transit networks through which the call is to be routed.
The presence of this facility in a call request packet completely overrides
the
sequence of RPOA transit networks that may have been specified by the
\fIRPOA subscription\fR \| facility (see \(sc\ 6.23.1).
.PP
If the DTE selects only one RPOA transit network, either the basic or extended
format of the \fIRPOA selection\fR \| facility may be used. If the DTE
selects more than one RPOA transit network, the extended format of the
\fIRPOA selection\fR \| facility is used. The appearance of both formats in a
\fIcall request\fR \| packet will be treated as a facility code not allowed.
.RT
.sp 1P
.LP
6.24
    \fIHunt group\fR
.sp 9p
.RT
.PP
\fIHunt group\fR \| is an optional user facility agreed for a period of
time. This user facility, if subscribed to, distributes incoming calls
having an address associated with the hunt group across a designated grouping
of
DTE/DCE interfaces.
.PP
Selection is performed for an incoming virtual call if there is at
least one idle logical channel, excluding one\(hyway outgoing logical channels,
available for virtual calls on any of the DTE/DCE interfaces in the group.
Once a virtual call is assigned to a DTE/DCE interface, it is treated as
a regular call.
.PP
When virtual calls are placed to a hunt group address in the case that
specific addresses have also been assigned to the individual DTE/DCE
interfaces, the \fIclear indication\fR \| packet (when no \fIcall accepted\fR
\| packet has been transmitted) or the \fIcall connected\fR \| packet transferred
to the calling
DTE optionally will contain the called DTE address of the selected DTE/DCE
interface and the \fIcalled line address modified notification\fR \| facility
(see
\(sc\ 6.26) indicating the reason why the called DTE address is different
from the one originally requested.
.bp
.PP
Virtual calls may be originated by the DTEs on DTE/DCE interfaces
belonging to the hunt group; these are handled in the normal manner. In
particular, the calling DTE address transferred to the remote DTE in the
\fIincoming call\fR \| packet is the hunt group address unless the DTE/DCE
interface has a specific address assigned. Permanent virtual circuits may
be assigned to DTE/DCE interfaces belonging to the hunt group. These permanent
virtual
circuits are independent of the operation of the hunt group. Some networks
may apply virtual call subscription time user facilities in common to all
DTE/DCE interfaces in the hunt group, place a limit on the number of DTE/DCE
interfaces in the hunt group, and/or constrain the size of the geographic
region that can be served by a single hunt group.
.RT
.sp 1P
.LP
6.25
    \fICall redirection and call deflection related facilities\fR
.sp 9p
.RT
.PP
The set of call redirection and call deflection optional user
facilities enables the redirection or the deflection of calls destined
to one DTE (the \*Qoriginally called DTE\*U) to another DTE (\*Qthe alternative
DTE\*U). The \fIcall redirection\fR \| facility (see \(sc\ 6.25.1) allows
the DCE, in specific
circumstances, to redirect calls destined to the originally called DTE; no
\fIincoming call\fR \| packet is transmitted to the originally called DTE
when such a redirection is performed. The call deflection related facilities
(see \(sc\ 6.25.2) allow the originally called DTE to deflect individual
incoming virtual calls
after reception of the \fIincoming call\fR \| packet by this originally
called DTE. A DTE may subscribe to the \fIcall redirection\fR facility,
to the \fIcall deflection\fR \fIsubscription\fR \| facility, or to both.
.PP
When a call to which the \fIcall redirection\fR \| or \fIcall deflection\fR \|
facilities are applied is cleared, the clearing cause shall be that generated
during the last attempt to reach a called DTE/DCE interface.
.PP
Call redirection or call deflection is limited to the network of the DTE
originally called.
.PP
The basic service is limited to one call redirection or call
deflection. In addition, some networks may permit a chaining of several call
redirections or call deflections. In all cases, networks will ensure that
loops are avoided and that the connection establishment phase has a limited
duration, consistent with the DTE time limit T21
(see Table\ D\(hy2/X.25).
.PP
When the virtual call is redirected or deflected, the \fIclear\fR
\fIindication\fR \| packet, when no \fIcall accepted\fR \| packet has been
transmitted by any DTE, or the \fIcall connected\fR \| packet transferred
to the calling DTE will
contain the called address of the alternative DTE and the \fIcalled line
address\fR \fImodified notification\fR \| facility (see \(sc\ 6.26), indicating
the reason why the called address is different from the one originally
requested.
.PP
When the virtual call is redirected or deflected, some networks may
indicate to the alternative DTE that the call was redirected or deflected,
the reason for redirection or deflection, and the address of the originally
called DTE, using the \fIcall redirection or call deflection notification\fR
\| facility
(see \(sc\ 6.25.3) in the \fIincoming call\fR \| packet.
.PP
Further information on the coding of the alternative DTE address is
given in Appendix\ IV/X.25.
.RT
.sp 1P
.LP
6.25.1
    \fICall redirection\fR
.sp 9p
.RT
.PP
\fICall redirection\fR \| is an optional user facility agreed for a
period of time. This user facility, if subscribed to, redirects calls destined
to this DTE when:
.RT
.LP
    1)
    the DTE is out of order, or
.LP
    2)
    the DTE is busy.
.PP
Some networks may provide call redirection only in case of 1).
Some networks may offer, in addition:
.LP
    3)
    systematic call redirection due to a prior request by the
subscriber according to criteria other than 1) and 2) above,
agreed to between the network and the subscriber.
.bp
.PP
In addition to the basic service, some networks may offer either one of
the following (mutually exclusive) capabilities:
.LP
    1)
    a list of alternative DTEs (C1, C2, .\|.\|.) is stored by the
network of the originally called DTE (DTE\ B). Consecutive
attempts of call redirection are tried to each of these
addresses, in the order of the list, up to the completion of the
call;
.LP
    2)
    call redirections may be logically chained; if DTE C has
subscribed to call redirection to DTE\ D, a call redirected
from DTE\ B to DTE\ C may be redirected to DTE\ D; call
redirections and call deflections may also be
chained.
.PP
The order of call set\(hyup processing at the originally called DCE as
well as the alternative DCE will be according to the sequence of \fIcall\fR
\fIprogress\fR \| signals in Table\ 1/X.96. For those networks that provide
systematic call redirection due to a prior request by the subscriber, the
systematic call redirection request will have the highest priority in the
call set\(hyup
processing sequence at the originally called DCE.
.sp 2P
.LP
6.25.2
    \fICall deflection related facilities\fR
.sp 1P
.RT
.sp 1P
.LP
6.25.2.1
    \fICall deflection subscription\fR
.sp 9p
.RT
.PP
\fICall deflection subscription\fR \| is an optional user facility agreed
for a period of time. This facility, if subscribed to, enables the DTE
to
request, by using the \fIcall deflection selection\fR \| facility (see
\(sc\ 6.25.2.2), that an individual call presented to it by transmission
of an \fIincoming call\fR \| packet be deflected to an alternative DTE.
.PP
The DCE may use a network timer, with a value agreed to with the
subscriber, to limit the time between the transmission to the originally
called DTE or an \fIincoming call\fR \| packet and the request by this
originally called DTE of deflecting the call. Once this timer has expired,
the originally called DTE will no longer be permitted to use the \fIcall
deflection selection\fR \| facility to deflect the call. If the originally
called DTE tries to deflect the call after the expiration of this internal
timer, the network clears the
call.
.RT
.sp 1P
.LP
6.25.2.2
    \fICall deflection selection\fR
.sp 9p
.RT
.PP
\fICall deflection selection\fR \| is an optional user facility which
may be used on a per virtual call basis. This facility may be requested by a
DTE only if it has subscribed to the \fIcall deflection subscription\fR \|
facility (see \(sc\ 6.25.2.1).
.PP
The \fIcall deflection selection\fR \| facility (see \(sc\(sc\ 7.2.1 and
7.2.2.10) may be used by the called DTE in the \fIclear request\fR \| packet
only in direct
response to an \fIincoming call\fR \| packet to specify the alternative
DTE address to which the call is to be deflected. If the \fIcall deflection
selection\fR \|
facility is used in the \fIclear request\fR \| packet, then the DTE must
also include any CCITT\(hy specified DTE facilities and user data to be
sent to the alternative DTE. Up to 16\ octets of user data may be included
in the \fIclear request\fR \|
packet in this case, if the original call was established without fast
select; up to 128\ octets of user data may be included in the \fIclear
request\fR \| packet if the original call was established with fast select.
If no CCITT\(hyspecified DTE
.PP
facilities are included in the clear request packet, then there will be
none in the incoming call packet to the alternative DTE. If no clear user
data is
included in the clear request packet, then no call user data will be included
in the incoming call packet to the alternative DTE. When requested for
a given virtual call, the network deflects the call to the alternative
DTE and does not respond to the calling DTE as a result of the clearing
of the originally called DTE/DCE interface. The X.25\ facilities that are
present in the \fIincoming call\fR \| packet transmitted to the alternative
DTE are those that would have been
present in the \fIincoming call\fR \| packet if the call was a direct call
from the calling DTE to the alternative DTE; moreover, the \fIcall redirection
or call\fR \fIdeflection notification\fR \| facility (see \(sc\ 6.25.3)
may also be present, if
supported by the network.
.PP
\fINote\fR \ \(em\ For an interim period, some networks may not allow a
deflected \fIincoming call\fR \| packet's contents to be modified, in which
case a
deflecting DTE is not permitted to use any user data or CCITT\(hydefined DTE
facilities in the \fIclear request\fR \| packet.
.bp
.PP
The bit 7 of the General Format Identifier (see \(sc 4.3.3) in the
\fIincoming call\fR \| packet transmitted to the originally called DTE or the
alternative DTE has the same value as the same bit in the \fIcall request\fR \|
packet.
.PP
If the network offers only the basic service and if a call redirection
or call deflection has already been performed, the DCE clears the call
as
indicated in Annex\ C when the \fIcall deflection selection\fR \| facility is
used.
.RT
.sp 1P
.LP
6.25.3
    \fICall redirection or call deflection notification\fR
.sp 9p
.RT
.PP
\fICall redirection or call deflection notification\fR \| is a user
facility used by the DCE in the \fIincoming call\fR \| packet to inform the
alternative DTE that the call has been redirected or deflected, why the call
was redirected or deflected, and the address of the originally called DTE.
.PP
The following reasons can be indicated with the use of the \fIcall\fR
\fIredirection or call deflection notification\fR \| facility (see \(sc\ 7.2.1
and\ 7.2.2.11):
.RT
.LP
    1)
    call redirection due to originally called DTE out of
order,
.LP
    2)
    call redirection due to originally called DTE busy,
.LP
    3)
    call redirection due to prior request from the originally
called DTE for systematic call redirection,
.LP
    4)
    call deflection by the originally called DTE.
.PP
Some networks may also use the following reason in
network\(hydependent cases not described in this Recommendation:
.LP
    5)
    call distribution within a hunt group.
.sp 1P
.LP
6.26
    \fICalled line address modified notification\fR
.sp 9p
.RT
.PP
\fICalled line address modified notification\fR \| is an optional user
facility used by the DCE in the \fIcall connected\fR \| or \fIclear indication\fR
\|
packets (see \(sc\(sc\ 7.2.1 and\ 7.2.2.12) to inform the calling DTE why
the called
DTE address in the packet is different from that specified in the \fIcall\fR
\fIrequest\fR \| packet.
.PP
When more than one address applies to a DTE/DCE interface, the
\fIcalled line address modified notification\fR \| facility may be used
by the DTE in the \fIclear request\fR \| packet (when no \fIcall accepted\fR
\| packet has been
transmitted) or the \fIcall accepted\fR \| packet, when the called DTE
address is
present in the packet and different from that specified in the \fIincoming
call\fR \| packet. When this facility is received from the DTE, the DCE
will clear the
call if the called DTE address is not one of those applying to the interface.
.PP
\fINote\fR \ \(em\ The DTE should be aware that a modification of any part of
the called DTE address field, without notification by the \fIcalled line
address\fR \fImodified notification\fR \| facility, may cause the call
to be cleared.
.PP
The following reasons can be indicated with the use of the \fIcalled\fR
\fIline address modified notification\fR \| facility in \fIcall connected\fR
\| or
\fIclear indication\fR \| packets transmitted to the calling DTE:
.RT
.LP
    1)
    call distribution within a Hunt Group,
.LP
    2)
    call redirection due to originally called DTE out of
order,
.LP
    3)
    call redirection due to originally called DTE busy,
.LP
    4)
    call redirection due to a prior request from the originally
called DTE according to criteria agreed to between the network
and the subscriber,
.LP
    5)
    called DTE originated,
.LP
    6)
    call deflection by the originally called DTE.
.PP
In \fIcall accepted\fR or \fIclear request\fR \| packets, the reason
indicated in conjunction with the use of the \fIcalled line address modified\fR
\fInotification\fR \| facility should be \*QCalled DTE originated\*U.
.bp
.PP
When several reasons could apply to a same call, the reason to be
indicated by the network in the \fIcall connected\fR \| or the \fIclear
indication\fR \|
packet by means of the \fIcalled line address modified notification\fR
\| facility is as specified below:
.RT
.LP
    1)
    the indication of a call redirection or call deflection in
the network has precedence over the indication of distribution
within a hunt group or over a called DTE originated
indication,
.LP
    2)
    the called DTE originated indication has precedence over
the indication of distribution within a hunt group,
.LP
    3)
    when several call redirections or call deflections have been
performed, the first one has precedence over the
others.
.PP
The called DTE address indicated in the \fIcall connected\fR \| or the
\fIclear indication\fR \| packets should correspond to the last DTE which
has been
reached or attempted.
.sp 1P
.LP
6.27
    \fITransit delay selection and indication\fR
.sp 9p
.RT
.PP
\fITransit delay selection and indication\fR \| is an optional user
facility which may be requested by a DTE for a given virtual call. This
facility permits selection and indication, on a per call basis, of the
transit delay applicable to that virtual call as defined in \(sc\ 4.3.8.
.PP
A DTE wishing to specify a desired transit delay in the \fIcall request\fR
packet for a virtual call indicates the desired value (see \(sc\(sc\ 7.2.1
and\ 7.2.2.13).
.PP
The network, when able to do so, should allocate resources and route the
virtual call in a manner such that the transit delay applicable to that
call does not exceed the desired transit delay.
.PP
The \fIincoming call\fR \| packet transmitted to the called DTE and the
\fIcall connected\fR \| packet transmitted to the calling DTE, will both
contain the indication of the transit delay applicable to the virtual call.
This transit
delay may be smaller than, equal to, or greater than the desired transit
delay requested in the \fIcall request\fR \| packet.
.PP
\fINote\fR \ \(em\ During the interim period when this optional user facility
is not yet supported by all networks, the indication of the transit delay
applicable to the virtual call will not be provided in the \fIincoming
call\fR \|
packet transmitted to the called DTE, if either a transit network or the
destination network does not support this facility.
.RT
.sp 1P
.LP
6.28
    \fITOA/NPI address subscription\fR
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ This facility is designated in Recommendation X.2 for
further study (FS).
.PP
\fITOA/NPI address subscription\fR \| is an optional user facility agreed
for a period of time for virtual calls.
.PP
When this facility is subscribed to, the DCE and the DTE shall always use
the TOA/NPI address format of the call set\(hyup and clearing packets
transmitted between the DCE and the DTE (see \(sc\ 5.2.1).
.PP
When the DCE needs to transmit an \fIincoming call\fR \| packet to a DTE
which has not been subscribed to this facility, and the calling DTE address
to be transmitted in this packet cannot be contained in the non\(hyTOA/NPI
address format of the address block, the DCE will include no calling DTE
address.
.PP
\fINote\fR \ \(em\ Some Administrations may provide a subscription\(hytime
option of the \fITOA/NPI address subscription\fR \| facility, allowing
the user to indicate that the DCE shall clear the call with cause \*Qincompatible
destination\*U and a specific diagnostic in the case described in that
last paragraph above, rather than include no calling DTE address.
.RT
.LP
.rs
.sp 9P
.sp 2P
.LP
\fBMONTAGE : \(sc 7 DE CETTE RECOMMANDATION SUR LE RESTE DE CETTE PAGE\fR
.sp 1P
.RT
.LP
.bp